On Jul 24, 2006, at 2:19 PM, David Jencks wrote:
On Jul 24, 2006, at 12:59 AM, Dain Sundstrom wrote:
One of the biggest problem with using the OpenEJB 2 containers in
3 is the extensive use of Geronimo's TransactionContextManager
class to track transaction related data and to demarc transaction
boundaries.
Exactly how is this a problem?
It means you can execute in a non geronimo environment. In general
most libraries go directly to the transaction manager to demarcate
transactions, and if that happens the transaction context manager
stops working.
I have just committed the necessary changes to remove this
dependency. We are now managing our own transaction data in the
EjbTransactionContext object (note this is different from the 1
TransactionContext class), and transaction demarcation is handled
by directly manipulating the transaction manager.
Maybe you could describe this a bit more. From this I'd guess you
have moved any services provided by the geronimo transaction
context into openejb. Since some of these were used by the
connector framework I'm wondering how you expect openejb to work
with the geronimo connector framework with this essential
functionality missing. Are you planning to rewrite the geronimo
connector stuff in openejb and have geronimo use it for web
containers?
We're currently not using the Geronimo connector stuff in openejb 3.
Openejb has had code since 0.x which can manage jdbc connections.
As for what we do in the future, I'm guessing we will just use the
jencks wrappers to work with the geronimo connector code.
The idea behind the transaction context was to provide a central
location to manage all the data associated with a transaction, and
to make it flexible enough to use with any container. Are you
saying that you think this is a bad idea? What design do you
propose instead?
Ever since I started trying to use geronimo components outside of
geronimo, I think this is a very bad design (and I was a big advocate
of this design). The fundamental problem is that is you can't use
code that uses the a transaction manager directly (all code except G
does this) and G services that use TCM at the same time. The two get
out of sync and then TCM throws exceptions.
As I mentioned in another email, I see two workable design alternatives:
1) wrap TCM in a TM and use that... this is the Jencks approach
2) remove TCM from G... the biggest user was openejb and after a
quick inspection, the other user is connector. The connector code
could be changed to manage it's own transaction state using
concurrent map and tx synchronization callbacks just like openejb has
done.
Both options have their benefits and drawbacks. I don't think this
is a problem that needs to be solved today.
In particular, what is supposed to happen when a servlet starts a
user tx and calls an ejb?
That one is easy. Any code can start a transaction and call an ejb.
The EJB code simply checks transactionManager.getTransaction() and
based on that it will decide to suspend and/or begin a new transaction.
-dain
