Hunsberger, Peter dijo: > Ugo Cei <[EMAIL PROTECTED]> writes: > >> Hunsberger, Peter wrote: >> > In general, this moves the responsibility for locking up a >> level which >> > isn't something I'd care to code, but if you're going to use JDO I >> believe you'll just get a last change wins result anyways, which is >> how you could manage this... >> >> If you implement this strategy, pretty soon you're going to >> end up with >> lost updates: Bob reads a record, Alice reads the same record, makes >> some changes and commits them, Bob makes some changes and >> commits them, >> overriding all of Alice's changes. >> >> To solve this problem, you need to implement an optimistic locking >> strategy using version fields. Bob would not be able to commit his >> changes because the version number he retrieved does not >> match the one >> stored in the database because Alice incremented it. > > Exactly my point about having to take responsibility for locking.... > >> I know Hibernate handles this, don't know about JDO > > Don't know, sooner or later you're always in a position where you either > have to trash an update or dead lock waiting for manual resolution, or > you have to implement versioning... > > For us, last update wins, we're not update intensive, but I'm waiting > for the day when someone forces us to wade through the audit log to > determine why there update didn't take.
The "last update wins" is the most used approaching in this cases. You can implement this using JDO. Best Regards, Antonio Gallardo
