I recently committed some code that provides a workaround for the sub-second resolution issue:
http://ci.apache.org/projects/ofbiz/site/javadocs/org/ofbiz/entity/jdbc/JdbcValueHandler.TimestampJdbcValueHandler.html -Adrian --- On Thu, 8/12/10, James McGill <[email protected]> wrote: > From: James McGill <[email protected]> > Subject: Optimistic locking based on timestamps > To: [email protected] > Date: Thursday, August 12, 2010, 1:15 PM > 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 >
