ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton Begin" <clinton.be...@gmail.com>
Subject Re: Dynamic queries w/o using <dynamic> tags in sql?
Date Tue, 13 May 2008 21:55:30 GMT
Josh...

I think you really need to look into this further, as you have a
fundamental misunderstanding of concurrency issues and databases.

* Separating the updates at the column level will NOT solve any
concurrency problem
* Concurrency issues are solved using either an optimistic or
pessimistic locking model at the row level

I recommend optimistic for most systems.

Table Josh
  id
  name
  weburl
  timestamp

update josh set ..., timestamp = now() where id = ? and timestamp = ?

If the timestamps don't match, it's not simply a technical problem of
reloading the object. You have to tell the user what happened... it's
a business exception. What if the user would have changed the name
differently if the URL was different or vice versa?

Pessimistic locking would lock the record so that it could not be
updated (and in some cases not even read) until it's unlocked.  It's
rare to need this type of locking in most business applications.

This is a pretty core concept in database programming that you should
understand before using iBATIS, Hibernate or even just JDBC.  One book
I can recommend is Java Transaction Processing (Mark Little), page 11
- 12.

Any other book recommendations from anyone else?

Cheers,
Clinton

On Tue, May 13, 2008 at 3:36 PM, Josh Joy <joshjdevl@gmail.com> wrote:
>
> Table Josh
>   id
>   name
>   weburl
>
> If one user wants to update the name, and another user wants to update the
> weburl...how to avoid concurrency issues if I have to do a reload of the
> entire object?
> Please let me know how to configure Ibatis to handle state concurrency
> issues if I have to fetch the entire object...
>
>
> Thanks,
> Josh
>
>
>
>
> On Tue, May 13, 2008 at 4:25 PM, Clinton Begin <clinton.begin@gmail.com>
> wrote:
> > So is it completely out of the question to just load up the whole
> > object and save the whole object?  Why do you ever need any
> > conditionals or partial updates at all?  The only reason is
> > performance (and even that really depends on the details).
> >
> > I don't see the problem here... :-/
> >
> > Clinton
> >
> >
> >
> >
> > On Tue, May 13, 2008 at 3:11 PM, Josh Joy <joshjdevl@gmail.com> wrote:
> > > Thanks Clinton for your reply.
> > >
> > > Just to clarify...I'm not looking for any performance
> optimizations...when I
> > > say best practices I'm referring to dynamically choosing which fields to
> > > update...
> > >
> > > it comes down strictly to simplicity and readability...I don't see a
> reason
> > > to fetch the latest entries for a row just so I can do an update (and
> how
> > > can I possibly guarantee it's the latest entry) nor do I see a reason to
> > > write multiple update statements or an if statement laden sql for all
> the
> > > possible update situations that can occur...
> > >
> > > I'll start poking around the api to see if I can wrap something up for
> my
> > > needs for now I guess... (unless anyone has any other suggestions, code
> > > snippets, or patches to share...)
> > >
> > > Thanks,
> > > Josh
> > >
> > >
> > >
> > >  On Tue, May 13, 2008 at 3:53 PM, Clinton Begin
> <clinton.begin@gmail.com>
> > > wrote:
> > > > Wow, I managed to lay down 3 or 4 run-on sentences in a row there...
> > > > Sorry Mr. McMillan...
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, May 13, 2008 at 2:52 PM, Clinton Begin
> <clinton.begin@gmail.com>
> > > wrote:
> > > > > Josh,
> > > > >
> > > > >  Some people do care enough about this to do something about it.
> And
> > > > >  yes, Hibernate is able to support it easily, because it has dirty
> > > > >  checking, object identity and generates the SQL for the update.
> > > > >
> > > > >  iBATIS is a SQL based framework.  It does not generate the SQL for
> > > > >  you, nor does it track dirty state or object identity etc.  It's
> > > > >  pretty safe to say that iBATIS will never support this in any way,
> > > > >  even if we do add SQL generation for convenience, the lack of dirty
> > > > >  checking etc. will keep this from ever being a practical
> possibility.
> > > > >
> > > > >  I recommend looking into your particular situation.  I'd bet that
> it
> > > > >  doesn't matter as much as you think it does, or if it does matter
> in
> > > > >  one or two cases -- handle those cases as a performance tweak.
> > > > >
> > > > >  To answer your question about best practices, I'm not sure anyone
> has
> > > > >  ever told me that this was a fully agreed upon best practice, but
I
> do
> > > > >  know a lot of people that think that premature performance
> > > > >  optimization is a practice to avoid...
> > > > >
> > > > >  Cheers,
> > > > >  Clinton
> > > > >
> > > > >
> > > > >
> > > > >  On Tue, May 13, 2008 at 2:37 PM, Josh Joy <joshjdevl@gmail.com>
> wrote:
> > > > >  >
> > > > >  >
> > > > >  > Hi,
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  > If I have an sql like the following...
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  > <select id="updateEmployees" >
> > > > >  >
> > > > >  >      Update  emp
> > > > >  >
> > > > >  >       <dynamic prepend="WHERE">
> > > > >  >
> > > > >  >               set
> > > > >  >
> > > > >  >
> > > > >  >             <isNotEmpty prepend="AND" property="id">
> > > > >  >
> > > > >  >                   empno=#id#
> > > > >  >
> > > > >  >             </isNotEmpty>
> > > > >  >
> > > > >  >             <isNotEmpty prepend="OR" property="name">
> > > > >  >
> > > > >  >                   ename=#name#
> > > > >  >
> > > > >  >             </isNotEmpty>
> > > > >  >
> > > > >  >       </dynamic>
> > > > >  >
> > > > >  > </select>
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  > Is there a way to instruct Ibatis to ignore nulls without having
> to
> > > actually
> > > > >  > use a dynamic tag? I would just like to set my bean entity
with
> the
> > > > >  > properties that I want updated, and leave null the ones I want
to
> > > ignore...
> > > > >  >
> > > > >  > I know in Hibernate there is a way to do this, is there an
> equivalent
> > > in
> > > > >  > Ibatis? It seems like a lot of xml code to write for all my
> > > updates...
> > > > >  >
> > > > >  > Is this not a best practice not to have dynamic updates, because
> I'm
> > > unsure
> > > > >  > why I would have to explicitly set this in the XML? As far
as I
> know,
> > > SQL
> > > > >  > updates (unless using a specific database vendor call) are
on a
> per
> > > table
> > > > >  > basis. Is it not recommended to have an entity and not always
> have to
> > > update
> > > > >  > all the fields? If I wanted to modify the Ibatis API for my
own
> needs
> > > for
> > > > >  > the updates, where would someone recommend I start?
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  >
> > > > >  > Thanks,
> > > > >  >
> > > > >  > Josh
> > > > >  >
> > > > >
> > > >
> > >
> > >
> >
>
>

Mime
View raw message