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: IBATIS 2.3.3, JDK 1.5 - Optimistic locking strategies
Date Thu, 09 Oct 2008 16:22:59 GMT
I'm re-reading your questions to make sure I understand.  To clarify my
previous answer, if all you have is the primary key of the object you want
to update, then you would need to perform two queries:

SELECT ID, TIMESTAMP
...edit...
UPDATE WHERE ID AND TIMESTAMP

If you can maintain the ID and the TIMESTAMP, then you don't need the first
select.  And no it doesn't need to be the same object, you could write the
ID and TIMESTAMP down on a piece of paper, shut down the server, start the
server, type in the ID and TIMESTAMP and perform the update.  If in the
meantime someone has modified the record in the database, your update will
report that 0 rows were modified, thus you have an optimistic lock
conflict.

There's no magic to it, really.  Does that answer the question?

Clinton

On Thu, Oct 9, 2008 at 10:14 AM, Clinton Begin <clinton.begin@gmail.com>wrote:

> Your fundamental question is obviously unclear.  Thus repeating your
> fundamental question is not helpful.  Clearly our fundamental answers are
> inadequate or are being fundamentally misunderstood.  Fundamentally, this is
> simple for everyone else who has ever achieved optimistic locking with
> iBATIS, as it is a fundamental part of most iBATIS persistence layer
> strategies.
>
> Would you like to revise your fundamental question, perhaps?
>
> Fundamentally?  ;-)
>
> To update an object with optimistic locking strategy, you need only the
> primary key.  I really don't understand where you're finding the problem.
> I could shut down the server in between updates and still maintain an
> optimistic locking strategy.  This is the fundamental (oops there it is
> again) benefit to using an optimistic locking strategy.  No object needs to
> be kept in scope, ever.  It doesn't even have to be the same object, the
> same statement or even the same application.
>
> Clinton
>
>
> On Thu, Oct 9, 2008 at 8:07 AM, mule_user <sgho@aol.com> wrote:
>
>>
>> My fundamental question was:
>>
>> Is there a way to achieve optimistic locking, if the "OldObject" and/or
>> the
>> update timestamp of the old object were NOT available in scope.
>>
>> It seems that the solution in iBATIS requires you to keep the "OldObject"
>> in
>> scope because, the where clause requires you to pass the ID of the
>> "OldObject" and update timestamp of the "OldObject".
>>
>> Otimistic locking requires keeping "OldObject" in scope in JDBC. I have
>> followed this principle using JDBC for years.
>>
>> I understand that iBATIS is built upon data mapping, not ORM. That being
>> said, I was hoping that there is an elegant solution using iBATIS, where I
>> do not have to keep "OldObject" in scope. I was hoping that I do not have
>> to
>> resort back to keeping "OldObject" in scope, similar to the way I am used
>> to
>> doing it in JDBC realm.
>>
>> Again, keep in mind that I can only use timestamp attribute, not version.
>> --
>> View this message in context:
>> http://www.nabble.com/IBATIS-2.3.3%2C-JDK-1.5---Optimistic-locking-strategies-tp19867989p19899728.html
>> Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
>>
>>
>

Mime
View raw message