Bill says: <quote> MethodOnlyEJBLock is erroneous by the spec. Spec says throw an exception on reentrancy if reentrant flag is not set to true. This lock has been replaced with an interceptor that does this behavior. Use org.jboss.ejb.plugins.lock.NoLock instead. </quote>
xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Georg Schmid" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, October 07, 2002 11:37 PM Subject: RE: [JBoss-user] How to avoid entity beans read lock ? Hi, (this is slightly off-topic but) I want to use the latest bug fix releases of JBoss in my production environment, so I have to tackle the removed MethodOnlyEJBLock situation. Could please someone who knows (Bill?) comment on the new NoLock and SimpleReadWriteEJBLock classes? What is the idea behind these changes? (Ok, I could speculate - nomen est omen - ...) Does the SimpleReadWriteEJBLock already work and how is it used correctly? Any hints would be much appreciated. BTW, JBoss does not support optimistic locking yet, and does not have a distributed object cache. If you cannot use the QueuedPessimisticEJBLock (which is usually the case when you need concurrent access to CMP EBs), and you need to synchronize your EBs, you can use the "row-locking" setting in the jbosscmp-jdbc.xml config file (in defaults or per EB) and let the database handle the synchronization. The SimpleReadWriteEJBLock may provide an alternative, but there seems to be no documentation yet (the last time I search the forums for it, it didn't turn up a single hit). Regards Georg ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
