> -----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.
Bill
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
