GoogleCodeExporter
commented
9 years ago [deleted comment]Open GoogleCodeExporter opened 9 years ago
GoogleCodeExporter
commented
9 years ago [deleted comment]I haven't looked at your test code yet, but are you sharing the same
Entity/objects in multiple threads and updating it multiple times? That check
is per instance of the entity.
If you are saving it from multiple threads without synchronizing the
access/persistence in your java code that is not safe ind. of Morphia.Original comment by scotthernandez on 28 Nov 2011 at 4:20
GoogleCodeExporter
commented
9 years ago Each thread does the following,
Fetch object
update object
persist object
Imagine a web app where many uses are working on the same data, this is a
typical use case.
I suspect the problem is in the DataStoreImpl, tryVersionedUpdate method.
If it is a newly persisted object, and multiple threads trying to update the
object get past the check on line 789, they will simply overwrite the previous
change.
if (oldVersion != null && oldVersion > 0) {
Perhaps on persisting an object Morphia should initialise the version to
something other than zero or null.
Original comment by seb_r...@hotmail.com on 28 Nov 2011 at 4:26
GoogleCodeExporter
commented
9 years ago Synchronizing the code is not a viable option the performance impact would be
too great. I have programmed hibernate before with optimistic locking and there
is no need to synchronize methods in the data access tier. The optimistic
concurrency algorithm is supposed to check if there is a newer version in the
database, if so then throw StaleObjectException or equivalent, so we can tell
the user that they are working with stale data.Original comment by seb_r...@hotmail.com on 28 Nov 2011 at 6:25
Original issue reported on code.google.com by
seb_r...@hotmail.comon 27 Nov 2011 at 11:50Attachments: