for what it is worth, the notion of pools becomes a bit moot for stateless
objects (the capsule). The VM should be able to create and collect the
instances of TX you throw at it.
Pools also lead to complex code (Cleaning up in a lock like you describe),
and while it will work, we end up with slower code under heavy load. If
what concerns you is the time to new a txcapsule, then a pool is OK (no
reuse)
marc
|-Original Message-
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of danch
|Sent: Monday, April 09, 2001 11:01 PM
|To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
|Subject: [JBoss-dev] Re: [JBoss-user] bug when server is under load
|
|
|I've moved this over to jboss-dev, where this bit will seem more
|appropriate.
|
|danch wrote:
|
| For what it's worth, I've seen similiar behavior under heavy threading
| (see archives under JBoss vs. Orion or Performance). I'm suspicious of
| the transaction interceptor (just because it seems to take about half of
| the time used in processing a request), but the code looks good. The
| message you're seeing (which I saw also in a multithreaded test) is
| particularly disturbing because the way JBoss' stateless session
| instance pool works, there should never be contention for a stateless
| session bean (as far as I can tell at any rate - I may be wrong).
|
|Well, what can I say: when I'm wrong I'm wrong. This has nothing to do
|with locks on beans. This was a lock on an internal bits of the JBoss
|transaction manager. The JBoss tm is written so that it attempts to
|reuse 'TxCapsule' instances by pooling them up in SoftReferences in a
|linked list. The problem is that they're not _quite_ available for reuse
|when the get put into the free list - they still have to do a hueristic
|check (and with trace on, throw something in the log) before they're
|unlocked.
|
|There _is_ a bit of a race condition here: it's possible for the capsule
|to get reused before (or while) it's doing its hueristic checks, which
|could potentially prevent the right thing from happening if a hueristic
|exception needs to happen. That, however, is highly unlikely in the test
|you're running.
|
|As far as fixing this bit of a race condition goes, I see two
|possiblilities:
|1. Release the instance in the finally clause. Problem is that there are
|plenty of cases where it shouldn't be release, leading to a flag for it.
|2. Make the method that initializes the capsule for re-use lock it. That
|way he'll wait for the hueristic checks to happen before blowing away
|the various state and status fields. We'll still see this message, but
|won't have this bit of a race condition behind it.
|
|If nobody objects, I'll implement option 2 tommorrow eve.
|
|For the record, there are some other things that make me nervous in this
|tm code: the TxCapsule and TransactionImpl have a circular dependency
|and in the process of cleaning up, the TransactionImpl will lose his
|referece to the TxCapsule before TxCapsule.commit() has actually
|returned to TransactionImpl.commit(). This just makes me nervous, like I
|said.
|
|-danch
|
|
|
|___
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
