I think your patch is very good. It helped me quite a bit. Thanks :)
Unfortunately, after having a look at the JTA implementation in Slide I discovered there might be a problem: SlideTransaction seems to guarantee to the enlisted XAResouces (in our case Slide services and practically Slide stores) that at most one transaction branch and thus thread may be active at a time. Also AbstractStore supports this as it waits to until all activity on the services that are enlisted for it cease.
Other implementations of TransactionManager surely will not guarantee such an assertion. This means stores and other implementations that rely on it are likely to fail in such an environment.
I may be wrong, but this is my impression. Anyone with deeper knowlegde is invited to correct me :)
If I am not wrong this implies that parallel access to a store - even for read only - is completely prohibited?!
Oliver
Grant Gongaware wrote:
Hi, this is my first real patch that I think will help the slide project.
Summary:
This patch introduces an new namespace definition parameter which allows you to define an alternate Transaction manager from either a Class or a JNDI lookup. The main benefits are for using slide in EJBs or other J2EE containers with built-in transaction managers. They can now enlist with larger application transactions and commit/rollback together. The new parameters is slide/namescape/definition/[transaction-manager]. It is optional and will default to the built in SlideTransactionManager. An example might look like:
...
<transaction-manager type="jndi">TransactionManager</transaction-manager>
...
Where the jndi lookup will be: java:comp/env/TransactionManager
Issues:
Additional changes had to be made to help with 3rd party transaction managers.
The XA Services needed to compare transaction id contents not just the standard references compares.
Read only operations in Locks and Security needed to join transactions if there was one so that changes to locks and permissions local to the transaction were read.
The Standstore service with caching enabled now uses the AbstractStore implementation on cache misses so that it can refer to the "force enlistment" option of the SlideToken.
The newer rdbms/J2EEStore now releases its connection before commits and rollbacks (so that overly watchful managed connections don't try to clean up too early).
Attached is a CVS diff patch from the latest revisions and a new Config reading class. Please test these out, and hopefully they're good enough to commit.
-Grant
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
