This is why I prefer to use PostGres but that's another story and of course the same problem could occur at the ms level, 1000 time
less though...
Jacques
From: "James McGill" <[email protected]>
We are having problems with the optimistic locking. With "enable-lock" set
on an Entity, updates in GenericDAO use a timestamp to do locking.
There are a number of issues with this. The biggest one is that it's not a
synchronized operation, so there's potential for a race condition within
customUpdate, which we are actually seeing in production.
I added code to introduce the "FOR UPDATE" expression when reading the
timestamp. This brings up another issue, that the timestamp field in MySQL
has resolution only to the second. So even if you don't have contention on
the optimistic lock SELECT, you still have to be lucky that your
transactions are more than one second apart.
I realize this is a fairly difficult problem to address, in general, and
that "fixing" many concurrency issues leads to risks of deadlock. But we
are seeing errors in data where the "last update wins."
Has anyone else had concurrency problems when multiple threads are updating
entities? Are there any locking provisions in the Delegator that would
allow us to prevent this kind of problem?
--
James McGill
Phoenix AZ
