Re: Stateful EJB and Local transactions...

Dror,

Thanks for the info.

Did you mean that the clean up was sent to the transaction pipe and since
the connection and transaction pipe are the same, it was sent to the
connection pipe as well ?

Now, on the subject of reverse connection pooling: I could not figure out
how David Jencks is doing it in the Firebird JCA adapter.

I am thinking that you need to avoid calling the App Server's Connection
Manager so that you handle the Managed Connection internally for a stateful
session with the EIS.

This is messy. I think there needs to be a way of telling the app server
that the transactional info is sent on the same pipe as the connection and
hence the cleaning up is done ehen the client calls remove on a stateful
EJB.

- Madhav



-----Original Message-----
From: Dror Harari [mailto:[email protected]]
Sent: Saturday, November 30, 2002 3:22 PM
To: [email protected]
Subject: Re: Stateful EJB and Local transactions...

> The more fundamental answer to your question involves the
> understanding of what is a transaction in an EJB. Each
> method is a separate transaction, and the methods of EJBs
> are designed/intended to be short or "tiny", stand-alone
> transactions. So, it makes perfect sense that you would
> see the container do the right thing by communicating an
> "end of transaction" following a call to the EJB's method.

This description might be valid if there is no client transaction under
which the stateful EJB is inovked. If the client invokes the EJB in an
established transactional context, then the client is in control when the
EJB method is marked as "Requires Transaction" or "Supports Transaction". In
between calls, the server must NOT commit the transaction - instead, since
the server wants to reuse the connection, it calls the end() method to
signify that the transactional work has ended (there is an option in the
specs to suspend and later resume work on the same transactional branch, but
I am still looking for a server that does it properly). Once the end()
method is called, the EIS connection is no longer associated with the
transaction and other clients may get it.

When the client in control decides to commit the transaction, the commit
request is delegated to the server's distributed transaction manager who is
responsible for coordinating the two-phase commit protocol, at the end of
which the transaction is committed.

So what wrong with this picture?

The problem lies with the definition of JTA and JTS (Java Transactions API
and Services). The spec tries to solve two separate issue and by mixing them
causes quite a few problems in scenarios such as Madhav's. One issue is the
orchestration of the two-phase-commit protocol among multiple resource
managers (adapters, datasources, etc.) The other issue is connection pooling
and the relationship between a connection and a transacrtion. In a nutshell,
JTA/JTS assume that a transaction in a given resource manager can live
unrelated to the connection (a concept known as two-pipes: one for the
connection, other for transaction management). While this is true for many
systems (mostly modern databases), it is not true for most legacy systems
(which are mostly single-pipe).

You cannot solve this problem by 'wrapping your JCA adapter in a stateless
EJB'. There is no state - hence the JCA connection goes away - hence an end
to the conversation you were planning to run with the EIS.

The way solve it is ugly and messy. The resource adapter implementation must
handle a 'reverse connection pooling' in its JCA implementation, making sure
connections that are associated with active transactions are kept internally
until the server resumes work on the same resource and transaction. This has
performance implications, but so does the concept of keeping a state at the
EIS.

You can find an example of this in the Firebird JCA adapter written by David
Jencks and now a SourceForge projectat
-http://sourceforge.net/projects/firebird

It could have been so much simpler if they had made this behavior
declarative, resource adapter writers would have must simpler task and the
overall system performance would have been beter for this reverse connection
pooling scheme is hard to get right and as it is done, it is not visible to
the application server and transaction manager....

Now I would not argue if stateful EJBs are evil or not - the fact of life is
that we need it once in a while - e.g., when you are integrating with a
conversational system at the back end. Somewhere, someone must match the
stateful/stateless models.

Hope this helps.

Dror Harari
Attunity

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email
to
[email protected] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff CONNECTOR-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".