Not sure how optimistic locking got into this mix, but DataContext
simply doesn't operate within an open transaction. It is
"disconnected", period.
So if you are concerned about memory use, maybe you should focus on
streaming BLOB implementation instead? Applications that have 30-40
thousands of objects (without LOBs) in the DataContext are not that
uncommon.
Also check out ResultIterator, maybe it'll fit your use patterns:
http://objectstyle.org/cayenne/userguide/perform/result-iterator.html
Andrus
On Aug 29, 2005, at 2:31 PM, Gili wrote:
> 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:50:05 EDT