StdServerSession/StdServerSessionPool -- JmsServerSession/Jm

[weston.price]

I just wanted to verify that the changes I have made in both the ASF implementation, as well as the JCA Inflow adapter are correct and that I understand the implications of both.

To make things a bit clearer, I created a TransactionDemarcationStrategy interface with the error() and end() methods. Depending upon the context either a LocalDemarcationStrategy or XADemarcationStrategy gets created.

Where this gets created is dependent upon the USE_OLD flag that is dependent on a system property (org.jboss.jms.asf.useold) which, by default is set to false.

So, when the run() method of StdServerSession or JmsServerSession gets executed, and based upon that flag, a TransactionDemarcation gets created. The USE_OLD == true flag requires the the Demarcation be created in the call to onMessage versus being created at Session run (ie UOW begins prior to the get of after the get has occured).

XA scenario:

In the case where the delivery is transacted (local tx false) XADemarcation gets constructed and a transaction is begun and the underlying XAResource gets enlisted. An errors thrown are handled in the demarcation error() method and as a result, the transaction is marked for rollback. The end() method then either commits or rollbacks depending upon completion of onMessage.

Local scencario:

This was the weird one in my mind and was largely prompted by the RuntimeException/BMT discussion. In this scenario local JMS transactions are used to 'dummy up' a transaction in the case of BMT to primarily handle the case where a listener throws a RunTime excpetion and the message should not be acknowledged. If the underlying JMS session is transcated the error() and end() method function like the XA scenario with the difference being that the JMS API is used to manage the transaction context.

Note the issue filed here:

http://jira.jboss.com/jira/browse/JBAS-3631

should be incorporated into this work as well.

[weston.price]

Also:

Driven by client request the following changes have been made the the StdServerSessionSession/Pool in the ASF implementation:

1) 3 new elements have been added to jboss.xml

 <LazyInitialization></LazyInitialization>
 <RecycleIdleSessions></RecycleIdleSessions>
 <IdleTimeOutMinutes></IdleTimeOutMinutes>

LazyInitialization being set to true requires that the StdServerSessionPool be lazily constructed with only the minimum pool size being created on startup.

RecycleIdleSesssion being set to true creates a JMS Reaper that functions in the same manner as our IdleRemover: removes idle JMS Sessions a configured interval (IdleTimeoutMinutes)

As a result, the StdServerSessionPool functions in a similar manner to the InternalManagedConnection pool. A semaphore has be implemented to managed acquiring session. Idle sessions are recycled with a PoolFiller maintaining the minimum pool size in the case that the session count falls below the minimum.

THis stuff is on a different branch at this point but my plan is to carry these features over to the JMS Inflow stuff as time permits.

[adrian.brock]

Looks ok to me.
The important part is that they are sufficiently tested,
which was the main reason why I didn't backport the previous work I did
from head.

[bill.burke]

Well, we'll find out how good it is when EJB3 RC9 goes out!

[weston.price]

You just never can let one post go by without saying something can you? No matter how useless or insulting. Don't you have a laptop to buy? :-)