Please excuse my stupidity!
Bill
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of danch
> (Dan Christopherson)
> Sent: Wednesday, June 06, 2001 2:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [JBoss-dev] Avoiding Locks for READ-ONLY Beans
>
>
> 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
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
