Transaction question

[jonathandfields]

This may be more of an ISPN question than MS but I thought I would ask here first. Are XA transactions supported? IOW, assuming the appropriate XA configuration for the various resources, will a JTA transaction involving JCR (Modeshape), JMS, and JPA (either directly or through JBPM) be an all-or-nothing transaction?

I had the impression in the past that it wasn't quite all there yet, but perhaps that has changed or I am wrong?

Thanks!

Jon

[rhauch]

UPDATED: Corrected the statement about using multiple sessions within a single transaction.

Yes, ModeShape does support XA transactions; see our documentation. For example, if Session.save() is within the context of a running transaction, then the changes made by that operation will be committed with the transaction and resulting events will be fired to listeners upon transaction commit. You can even call save() multiple times on the Session within the same transaction, though you should not use multiple Sessions within a single transaction and multiple Sessions can even participate in the same transaction, presuming the transaction is started and active on the current thread before the sessions are created.

However, there is still one caveat: while the repository's Infinispan cache is enlisted in the transaction, the cache stores are technically not enlisted. Infinispan will instead write to the cache store upon transaction commit. I'm not sure what Infinispan does to the transaction should that write fail during the commit. The ISPN community would be a better place to get details on this behavior. I do know that the Infinispan team is actively working on addressing this in ISPN 6.x; see their mailing list archive for details.

[jonathandfields]

Thanks for the quick response. I will seek further clarification in the ISPN resources for the caveat that you mentioned. Do you know if there is an ISPN issue in JIRA explicitly tracking this, or is this just a known limitation?

My primary concern at this point is that updates to all resources enlisted in a transaction are rolled back if there is an exception thrown during execution of the (CMT) method - and that seems to be the case. If the only case that is not handled is if the write to the ISPN cache loader fails, I can live with that,  by making sure that the underlying cache loader store is very reliable. Since I'm using BDBJE, I can put the files on a very reliable file system, and then my only significant point of failure would be the BDBJE software itself, which is presumably pretty solid.

Thanks!

Jon

[rhauch]

I believe it's being worked under ISPN-604.

My primary concern at this point is that updates to all resources enlisted in a transaction are rolled back if there is an exception thrown during execution of the (CMT) method - and that seems to be the case.

At this point, an exception within a CMT method will cause the transaction to rollback, and ModeShape and ISPN will all respond appropriately by ensuring none of the changes made during the transaction are persisted. (Remember that a transaction's uncommitted changes will not be seen by other transactions.)

f the only case that is not handled is if the write to the ISPN cache loader fails, I can live with that,  by making sure that the underlying cache loader store is very reliable. Since I'm using BDBJE, I can put the files on a very reliable file system, and then my only significant point of failure would be the BDBJE software itself, which is presumably pretty solid.

I agree, and this is really why the ISPN guys don't think the current behavior is too big a deal. Sure, they do want to enable JTA-compliant cache stores, but quite a few cache stores will never really be made to be JTA compliant anyway.

[jonathandfields]

Thanks, very helpful information.

One more "operational" question if you don't mind.... How does the Lucene index come into play? Is it also enlisted in the transaction in some way? I am wondering if it is possible to  have a situation where ISPN and the Lucene indexes become out of synch, causing false query results? (I have faced that problem myself with custom RDBMS + Lucene applications). If that is possible, is there any way to detect and repair such an inconsistency? I suppose I am thinking of some kind of "fsck" kind of utility.....

Thanks!

[rhauch]

How does the Lucene index come into play? Is it also enlisted in the transaction in some way?

The indexes are updated during the transaction commit, so the updated content will be visible in queries only upon successful transaction commit.

[piratew]

Hi guys,

hope you don't mind asking a related question. Randall you stated:

Randall Hauch schreef:

UPDATED: Corrected the statement about using multiple sessions within a single transaction.

You can even call save() multiple times on the Session within the same transaction, though you should not use multiple Sessions within a single transaction and multiple Sessions can even participate in the same transaction, presuming the transaction is started and active on the current thread before the sessions are created.

Does it matter if the multiple session are accessing different repositories? So one session goes to repository A and the second session goed to repository B?

regards,

Michael

[rhauch]

Each repository is completely isolated from all other repositories -- except if they running in the same engine, and then the only commonality is that they're lifecycle is being managed by the same engine. Other than that, repositories are completely independent.

Therefore, a session from one repository and a session from another repository would be treated in a JTA transaction as separate XA resources.

[piratew]

thanks for the info Randall!