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
