fortunately, you seem to be right!
But my mistake was not that I though there should be more than one thread per transaction branch. This was clear. I thought Slide limited access to a store to just one transaction branch (and thus thread) at a time.
This is incorrect. All it does is limiting access to a store to at most one transaction branch *of a distributed transaction* at the same time. This means while one transaction branch of one distributed transaction accesses a store another transaction branch of a *different* distributed transaction - as started from a second servlet call - can aceess the store at the same time.
Correct? Or am I still confusing things (as these JTA things actually are confusing, aren't they?) ;)
Thanks again :)
Oliver
Grant Gongaware wrote:
Hi Oliver,
To me it seems parallel access is achieved through multiple transactions (each from a different thread) calling read and write methods. In my usage cases which use the J2EE store, 2 or more treads begin reading the store, each calls begin() and each gets its own Xid, and in my case each thread gets a JDBC connection, then each thread makes sequential calls to the RDBMS.
I haven't tested branching.
I've been using a Jboss 3.x transaction manager, which has a similar one thread per transaction implementation.
-Grant
Oliver Zeigermann wrote:
Hi Grant,
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
