Removed dependency on Geronimo TransactionContextManager

[Dain Sundstrom <da...@iq80.com>]

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.   
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.   I'd like to drop the  
transaction policy code from the 2 tree entierly and simply convert  
the 1 transaction code to an javax.interceptor.Interceptor  
implementation, but that is for another thread.

Anyways, we are one big step closer merged the 1 and 2 code bases :)

-dain

Re: Removed dependency on Geronimo TransactionContextManager

[Dain Sundstrom <da...@iq80.com>]

On Jul 24, 2006, at 11:22 PM, David Blevins wrote:

> On Jul 24, 2006, at 2:32 PM, Dain Sundstrom wrote:
>
>> On Jul 24, 2006, at 1:47 PM, David Blevins wrote:
>>> In the interest of keeping 3 and 2 close together as to make it  
>>> as easy as possible for Geronimo to upgrade to 3, what do you  
>>> think about merging that back into 2?
>>
>> I'd love to merge this back into 2 but that will be difficult.   
>> The problem is Geronimo needs to have all transactions demarcated  
>> on TransactionContextManager.  If you go directly to the  
>> TransactionManager, the TransactionContextManager will not know  
>> that the transaction state changed under it's feet and will enter  
>> an "inconsistent state".
>>
>> If we want to merge this into OpenEJB 2 we will either need to  
>> create a TransactionManager implementation that is a wrapper  
>> around TransactionContextManager (there is one in the jencks  
>> project that does that), or we need to convince Geronimo to drop  
>> the TransactionContextManager and just use TransactionManager  
>> directly.
>
> If I understand you correctly, either approach leads to more or  
> less the same change in OpenEJB 2?  I.e. big changes to Geronimo  
> are not required, right?

Yes.  Either way, openejb 2 just gets a merge from 3, and geronimo  
does not require any changes, it is just an option.

> On the jencks project note, is this what ActiveMQ et all use when  
> they run in Geronimo or do they write directly against the TCM?

They use a TM and bypass the TCM.  If they coded against the TCM they  
would not be able to run in other servers.

>> The first first option may be possible, but I expect there to be  
>> sublet bugs in the wrapper layer, and the second would be a pretty  
>> big move for Geronimo.  After this work, removing TCM from  
>> geronimo will be much easier since OpenEJB was the single biggest  
>> user of the service.  The only other service I'm aware of that  
>> uses it is the connector code.  Another nice benefit of dropping  
>> the TCM is geronimo components will be much more useable outside  
>> of geronimo which will expand the community.
>>
>> Anyway, I'll if you want I can take a deeper look at what it will  
>> take to merge this work back into 2.
>
> That would be great if you could.

ok

-dain

Re: Removed dependency on Geronimo TransactionContextManager

[David Blevins <da...@visi.com>]

On Jul 24, 2006, at 2:32 PM, Dain Sundstrom wrote:

> On Jul 24, 2006, at 1:47 PM, David Blevins wrote:
>> In the interest of keeping 3 and 2 close together as to make it as  
>> easy as possible for Geronimo to upgrade to 3, what do you think  
>> about merging that back into 2?
>
> I'd love to merge this back into 2 but that will be difficult.  The  
> problem is Geronimo needs to have all transactions demarcated on  
> TransactionContextManager.  If you go directly to the  
> TransactionManager, the TransactionContextManager will not know  
> that the transaction state changed under it's feet and will enter  
> an "inconsistent state".
>
> If we want to merge this into OpenEJB 2 we will either need to  
> create a TransactionManager implementation that is a wrapper around  
> TransactionContextManager (there is one in the jencks project that  
> does that), or we need to convince Geronimo to drop the  
> TransactionContextManager and just use TransactionManager directly.

If I understand you correctly, either approach leads to more or less  
the same change in OpenEJB 2?  I.e. big changes to Geronimo are not  
required, right?

On the jencks project note, is this what ActiveMQ et all use when  
they run in Geronimo or do they write directly against the TCM?

> The first first option may be possible, but I expect there to be  
> sublet bugs in the wrapper layer, and the second would be a pretty  
> big move for Geronimo.  After this work, removing TCM from geronimo  
> will be much easier since OpenEJB was the single biggest user of  
> the service.  The only other service I'm aware of that uses it is  
> the connector code.  Another nice benefit of dropping the TCM is  
> geronimo components will be much more useable outside of geronimo  
> which will expand the community.
>
> Anyway, I'll if you want I can take a deeper look at what it will  
> take to merge this work back into 2.

That would be great if you could.

-David

Re: Removed dependency on Geronimo TransactionContextManager

[Dain Sundstrom <da...@iq80.com>]

On Jul 24, 2006, at 1:47 PM, David Blevins wrote:

> On Jul 23, 2006, at 9:59 PM, 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.  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.
>
> Huge improvement.

Thanks :)

>> I'd like to drop the transaction policy code from the 2 tree  
>> entierly and simply convert the 1 transaction code to an  
>> javax.interceptor.Interceptor implementation, but that is for  
>> another thread.
>
> +1 to that.
>
>> Anyways, we are one big step closer merged the 1 and 2 code bases :)
>
> In the interest of keeping 3 and 2 close together as to make it as  
> easy as possible for Geronimo to upgrade to 3, what do you think  
> about merging that back into 2?

I'd love to merge this back into 2 but that will be difficult.  The  
problem is Geronimo needs to have all transactions demarcated on  
TransactionContextManager.  If you go directly to the  
TransactionManager, the TransactionContextManager will not know that  
the transaction state changed under it's feet and will enter an  
"inconsistent state".

If we want to merge this into OpenEJB 2 we will either need to create  
a TransactionManager implementation that is a wrapper around  
TransactionContextManager (there is one in the jencks project that  
does that), or we need to convince Geronimo to drop the  
TransactionContextManager and just use TransactionManager directly.   
The first first option may be possible, but I expect there to be  
sublet bugs in the wrapper layer, and the second would be a pretty  
big move for Geronimo.  After this work, removing TCM from geronimo  
will be much easier since OpenEJB was the single biggest user of the  
service.  The only other service I'm aware of that uses it is the  
connector code.  Another nice benefit of dropping the TCM is geronimo  
components will be much more useable outside of geronimo which will  
expand the community.

Anyway, I'll if you want I can take a deeper look at what it will  
take to merge this work back into 2.

-dain

Re: Removed dependency on Geronimo TransactionContextManager

[David Blevins <da...@visi.com>]

On Jul 23, 2006, at 9:59 PM, 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.  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.

Huge improvement.

> I'd like to drop the transaction policy code from the 2 tree  
> entierly and simply convert the 1 transaction code to an  
> javax.interceptor.Interceptor implementation, but that is for  
> another thread.

+1 to that.

> Anyways, we are one big step closer merged the 1 and 2 code bases :)

In the interest of keeping 3 and 2 close together as to make it as  
easy as possible for Geronimo to upgrade to 3, what do you think  
about merging that back into 2?

-David

Re: Removed dependency on Geronimo TransactionContextManager

[Dain Sundstrom <da...@iq80.com>]

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

Re: Removed dependency on Geronimo TransactionContextManager

[David Jencks <da...@yahoo.com>]

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?

> 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?

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?  In particular, what is supposed to happen when a servlet  
starts a user tx and calls an ejb?

thanks
david jencks


>   I'd like to drop the transaction policy code from the 2 tree  
> entierly and simply convert the 1 transaction code to an  
> javax.interceptor.Interceptor implementation, but that is for  
> another thread.
>
> Anyways, we are one big step closer merged the 1 and 2 code bases :)
>
> -dain