[jboss-user] [JCA/JBoss] - Re: Why is jboss closing my connection?

[adrian@jboss.org]

"teknokrat" wrote : 
  | If there are better ways to do this I am all ears.
  | 

Use a transaction.

What you have is a unit of work. 
startWork();
doStuff();
endWork();

JTA Transactions are natural units of work.
You can mark when the work starts and when it finishes.
More importantly, you can decide when it should timeout and resources get released.

Don't get confused about performance. A JTA transaction is just a thread
local marker, its not "heavy" like a real jdbc transaction.
It can become "heavy" if you enlist something like a jdbc connection 
in the JTA transaction.

Stateful sessions are also units of work
but they have some bad semantics in terms of resource allocation.

e.g. Suppose the client starts a session, you allocate a tcp/ip connection
(a limited resource) per session, but the client then vanishes, e.g. if it is a user
interface they go to lunch or go home without ending the session (properly).

After a certain period of inactivity JBoss will passivate the session (write it to disk)
after a further period of inactivity it will remove the session altogether.

Question: How are you going to recover the tcp/ip connection if the session is passivated
and then reactivated? You certainly can't serialize a tcp/ip socket.
For the same reason, you can't replicate the session across a cluster if you
want the session to failover.

Another bad feature of SFSB is that a serious error (an EJB/RuntimeException)
will mean that ejbRemove() is NOT invoked. That means there is no
way for the EJB instance to tell the server to release the resources it allocated.
You will leak connections! 
The EJB spec says you need to do some extra work to cater for this situation,
but this is usually hard to do.

What this shows is that in general it is bad idea to have the EJBs control
resource allocation. You should let the server do it. If you need to use the
same connection across requests, use the JTA transaction notion
to define what those requests are and let the server "cache" the connection
against the transaction. 
It's called "Transaction Stickiness" on the WIKI page describing the pooling.

Anyway, that's enough free consulting. :-) All I can say is that you have been
warned that what you are doing is anti-pattern and I've listed some of the
main reasons why, plus given you an idea of how to redefine what you
are doing as a "unit of work" with better semantics.

And I didn't even mention the horrible BMT SFSB semantics. :-)

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4055304#4055304

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4055304