> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
> Sent: Saturday, May 27, 2000 5:52 AM
> To: JBoss Developers
> Subject: [jBoss-Dev] Transactions
>
>
> As part of the work on JDBC pools, I check whether there's
> currently a transaction. I'm not finding any, which is a little
> confusing. In my ejb-jar.xml I have:
>
> <transaction-type>Container</transaction-type>
>
> Which I though meant container-managed persistence and that every
> EJB call would be part of a transaction. But when the bean gets a pool
> reference (without using a resource reference - see previous message on
> jBoss user) and the pool checks for a transaction, there isn't one:
>
> TransactionManager tm = (TransactionManager)ctx.lookup(tmJndiName);
> if(tm.getStatus() != Status.STATUS_NO_TRANSACTION) {
> // never happens
> ...
> }
>
> Are entity beans the only ones that get Transactions? I didn't
> think this was true - because a session bean can make updates via a
> datasource, right?
relax..
There is always "how did we do it in jBoss 1.0" to help us ...
ok the session bean can see the transaction through the JTA interfaces. A
bean can perfectly start a transaction in BMT mode. (Bean Managed Tx,
personal lingo)
> Could this be because I bind an instance of TransactionManager to
> a JNDI name once at the beginning, so it has the wrong ThreadLocal, and
> thus the wrong information? Would the TransactionManager need to be bound
> for every method invocation to get the right ThreadLocal? Then we'd need
> a private JNDI namespace somehow, I guess. This doesn't sound right.
in jBoss 1.0 we bind (jonas's Tx man) once and for all. The idea of the
ThreadLocal is that the "ThreadLocal" variable identifies for a each thread
that comes along a tx associated with it based on the hash of the Thread
(the thread is the key). By definition this is a "VM centric" solution.
You need to bind once and for all, create a "Thread" based map in the VM
that keeps track of these associations. I don't see a fundamental problem
with the variable seeing the bean invocations and the container, in fact I
would want to make sure that the container layers when they say "get()" on
the TL variable, see teh right Tx that was started from the bean and
propagate/act accordingly.
in jBoss 1.0 the stuff is bound per VM at startup (see jboss1.0:
Server.java::startTXMon()) what is bound is a "Current" and it is unique per
VM. Your hack looks good even though I am no JTA/JTS expert...
It's something else
regards
marc
> Aaron
>
>
>
