Hi,
Just curious why we chose to implement optimistic locking like we did.
The reason I ask is that I want to be able to:
add 1000 objects
flush to database
add 1000 objects
...
many objects later...
dataContext.commit()
now, I should be able to dataContext.rollback() at any time and this
should undo all changes all the way back to the beginning of the
context. I've been talking to Mike on IRC and he says that to his
knowledge it is unlikely we can implement the above behavior because
right now optimistic locking caches the original attribute value so that
at commit time we can compare it to the DB version and throw an
exception if optimistic locking failed. This incurs heavy memory usage.
Now, if we were only remembering a version/timestamp per row, it would
be much easier to implement this. I ask because Hibernate can already
support this behavior using this code:
// execute 1000 times
session.saveOrUpdate(object);
...
session.flush();
session.clear();
...
// many objects later
...
session.commit() or session.rollback() will go all the way past the
session.flush()/clear() calls.
I am sorry for all these questions but I am rather new to all of this :)
Thank you,
Gili
-- http://www.desktopbeautifier.com/
This archive was generated by hypermail 2.0.0 : Mon Aug 29 2005 - 14:31:43 EDT