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 <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> 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. >> >> >
