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.
regards
Georg
___ ___
| + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
|_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
