Bill Burke wrote: > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED]]On Behalf Of Georg >>Rehfeld >>Sent: Wednesday, June 06, 2001 1:11 PM >>To: [EMAIL PROTECTED] >>Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans >> >> >>Hello Bill, hi all, >> >> >>>- What's wrong with doing a Context lock, but not doing a transactional >>> >>lock >> >>>for read-only beans? If you do this you'll still be spec compliant, >>>correct? How would this affect your performance results? I'm >>> >>pretty sure >> >>>the spec says it's up to the Container developer to decide how to synch >>>beans per transaction, but you are required to make EntityBeans single >>>threaded. >>> >>It was reported, that trying to access the beans concurrently without >>TX and with non-reentrant beans leads to very similar LOCKING-WAITING >>behaviour as within a TX. >> >>But if you access outside a TX AND have the bean reentrant there >>is no LOCKING-WAITING anymore without any change to existing >>code. I don't think, this reentrnce really is a problem, data >>gotten outside a TX must be considered inconsistent anyway, so >>why not let hundreds of clients do getters concurrently, where is >>the problem? >> >>Concurrent access from clients accessing inside different TXs is >>still serialized, the only potential danger with reentrant is, >>when DIFFERENT clients having THE SAME TX access the bean >>concurrently, how should this normally be possible (except for the >>allowed callback case)? >> >>Before modifying code that makes JBoss incompliant, why not simply >>use existing spec conform features, it's all there, just use it! >> >> >>>- All in all, IMHO, Transactional EntityBean locking should be removed >>>totally from JBoss. This locking is totally useless when you have more >>> >>than >> >>>one instance of JBoss hitting the sam DB anyways. Let the DB handle the >>>locking. If you want your EntityBeans synched across >>> >>transactions use the >> >>>select-for-update options if you're using CMP, or with BMP, >>> >>manage the DB >> >>>locks yourself. >>> >>Oh, but then you cannot use commit option A anymore. So for A the >>serialization IS required, and with B and C someone has to implement >>multiple instances of the bean before removing the locking at >>container level. >> >> > > Why do you have to implement multiple instances of the bean? For a quick > fix, just take out the code that waits for the EntityBean to leave the > transaction in EntityInstanceInterceptor. Leave the locking code that comes > after the transaction waiting stuff, it's used to make the bean > single-threaded(correct?). This will still work for commit-option 'A' won't > it? If you keep the bean single-threaded, option 'A' is not violated. > What about this scenario: ================================================================== Transaction A Transaction B Lock Entity B Context Wait for entity b context. Call into business method Modify data Unlock Entity B Context Lock entity B Context Read data A Modified Rollback! ================================================================= Now transaction B has read data that has never been modified. -danch
Confidential e-mail for addressee only. Access to this e-mail by anyone else is unauthorized. If you have received this message in error, please notify the sender immediately by reply e-mail and destroy the original communication.
