Hey,
I was thinking last night about this... couldn't sleep :(
I think I kinda see the need for a non-distributed implementation of full
JTA and needed TS. It would need to be pluggable just like the other
"services" to the container right now.
If we do non distributed we can make a fast stand alone server. I mean
people don't really use web transactions that well right now, and so first
they need to learn them, and then we might see a need to actually distribute
the transaction (and do all the fancy Propagation of Context she refers
too).
In short, writing that simple interface for pluggability, (we need the
thread association methods and no they are not resume and suspend ;-) is
trivial.
public interface SimpleTM {
// All the javax.transaction.TransactionManager methods
// This method disassociates the thread and Tx
public Transaction disassiociateThread()
// This method associates the thread
public void associateThread(Transaction tx)
}
no RMI, no distribution, just in-VM TM, real light, real fast. We do the
container calls right ;-) but the stuff works inVM Want the JOnAS TM?
putting the adapter is mostly changing the code in jboss1.0 and you provide
the jboss.xml file. However right now it is one TM per VM and probably we
should keep it that way.
marc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Tuesday, August 01, 2000 9:31 AM
> To: jBoss Developer
> Subject: Re: [jBoss-Dev] rmi,transactions,orbs [was: TransactionImpl]
>
>
> Hey
>
> Carlos Pita wrote:
> > >On the other hand, with pure RMI, no service context fields exist
> > >in the JRMP protocol to transport a transaction context (or any other
> > >kind of context). So, JOnAS on top of RMI transports the transaction
> > >context as an explicit extra parameter in remote method calls.
> > >However, with rmi-iiop, the way to transport the transaction service
> > >context should be as for Jeremie and JOnAS.
>
> This isn't strictly true. There are hooks for service context fields in
> JRMP, they're just not exposed publically. They will (most likely) be
> public in JDK 1.4.
>
> > 6) Most orbs offer another services (persistence, events,
> security) which
> > are pertinent to ejb containers implementations.
>
> I think we are better off by doing persistence and security ourselves.
> Events is provide by SpyderMQ.
>
> > 7) The corba component model is a more robust ground for a ejb container
> > implementation
>
> Hm.. more robust ground than.. what?
>
> > and the way to align with it (not necessarily now and
> > possibly never!) is building it on top of a corba (2.3 or 3? we
> surely need
> > a POA) orb.
>
> I don't mind plugging in a ORB for the distribution of the container,
> but does it have to be more tightly coupled than that?
>
> /Rickard
>
> --
> Rickard �berg
>
> Email: [EMAIL PROTECTED]
> http://www.telkel.com
> http://www.jboss.org
> http://www.dreambean.com
>
>
