ModeShape
  1. ModeShape
  2. MODE-1123

ModeShape should participate in local JTA transactions

    Details

    • Type: Enhancement Enhancement
    • Status: Closed Closed (View Workflow)
    • Priority: Blocker Blocker
    • Resolution: Won't Fix Won't Fix
    • Affects Version/s: 2.4.0.Final
    • Fix Version/s: None
    • Component/s: JCR, Storage, Transactions
    • Labels:
      None
    • Affects:
      Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration
    • Estimated Difficulty:
      Medium
    • Similar Issues:
      Show 10 results 

      Description

      ModeShape should be able to be used by local JTA clients when configured to use repository sources that are already JTA-compatible. For example, when ModeShape is deployed within an application server, using JCR from within EJBs requires that ModeShape be able to participate in local transactions (making all changes to the underlying stores in a JTA-compliant fashion). Since not all connectors work with JTA-compatible sources, only some configuration must be provided.

        Issue Links

          Activity

          Hide
          George Gastaldi
          added a comment -

          Actually there are three properties that must be set in Hibernate so this may work:

          <property name="current_session_context_class">jta</property>          
          <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
          <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
          
          Show
          George Gastaldi
          added a comment - Actually there are three properties that must be set in Hibernate so this may work: <property name= "current_session_context_class" > jta </property> <property name= "hibernate.transaction.factory_class" > org.hibernate.transaction.JTATransactionFactory </property> <property name= "hibernate.transaction.manager_lookup_class" > org.hibernate.transaction.JBossTransactionManagerLookup </property>
          Hide
          George Gastaldi
          added a comment -

          we'll need to update the Reference Guide and create some good test cases (ideally, both unit tests in 'modeshape-connector-store-jpa' and integration tests in 'modeshape-integration-tests)

          Show
          George Gastaldi
          added a comment - we'll need to update the Reference Guide and create some good test cases (ideally, both unit tests in 'modeshape-connector-store-jpa' and integration tests in 'modeshape-integration-tests)
          Hide
          George Gastaldi
          added a comment -

          Transcript from the IRC:

          #modeshape

          [15:31] <rhauch> gastaldi: first off, I was wrong ... there is a benefit to changing just the JPA connector to support JTA transactions, and we actually don't have a lot of work to do there.
          [15:31] <rhauch> gastaldi: This will enable using ModeShape with local JTA clients under certain situations ...
          [15:32] <rhauch> gastaldi: as long as the JDBC DataSource is registered with the app server as being an XA DataSource, and that XADataSource is available in JNDI,
          [15:33] <gastaldi> oh
          [15:33] <gastaldi> So the XA part is left to the DataSource then
          [15:33] <rhauch> gastaldi: and the ModeShape repository is set up to use a JPA source using the XADataSource (found via JNDI) and the system workspace is set up to also use the same or a similarly set up JPA source,
          [15:33] <rhauch> gastaldi: then it should work just fine.
          [15:34] <gastaldi> But it should be changed to use JTA as the transaction factory , right ?
          [15:34] <rhauch> gastaldi: in such a configuration, ModeShape doesn't store any information outside of JDBC, other than the Lucene indexes (which will get updated only upon successful txn commits)
          [15:34] <gastaldi> ah right, that´s was my doubt
          [15:35] <rhauch> gastaldi: actually, we'll need to make sure Hibernate is configured correctly (or figure out whether Hibernate can auto-discover the transaction capability of the source)
          [15:35] <gastaldi> It´s just a matter of configuring 3 properties
          [15:35] <rhauch> gastaldi: We're actually calling 'EntityTransaction.commit()' or 'rollback()', never calling directly on the connection.
          [15:35] <gastaldi> right
          [15:36] <gastaldi> Here is what needs to be added:
          [15:36] <gastaldi> <property name="current_session_context_class">jta</property> <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property> <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property>
          [15:37] <gastaldi> the datasource may be XA enabled or not, it does not matter
          [15:38] <rhauch> gastaldi: we have to do that even if the data source is XA-enabled (and registered)?
          [15:38] <gastaldi> Yes, it´s transparent to JTA
          [15:38] <gastaldi> When these properties are set, JTA is used as the underlying transaction
          [15:39] <gastaldi> and if the Datasource is a XADataSource, it will participate in the transaction in a two-phase commit
          [15:39] <gastaldi> in other words, it will work fine
          [15:39] <gastaldi>
          [15:39] <rhauch> gastaldi: ok. we'll have to figure out what needs to be configurable in the JpaSource then. Maybe just the "TransactionManagerLookup" class ?
          [15:40] <gastaldi> yes, I think so
          [15:40] <rhauch> gastaldi: ok. we'll also want to decrease the scope of MODE-1123
          [15:40] <jbossbot> jira MODE-1123 Modeshape should support JTA [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/MODE-1123
          [15:40] <gastaldi> sure
          [15:40] <rhauch> gastaldi: because this will only work in some situations

          Show
          George Gastaldi
          added a comment - Transcript from the IRC: #modeshape [15:31] <rhauch> gastaldi: first off, I was wrong ... there is a benefit to changing just the JPA connector to support JTA transactions, and we actually don't have a lot of work to do there. [15:31] <rhauch> gastaldi: This will enable using ModeShape with local JTA clients under certain situations ... [15:32] <rhauch> gastaldi: as long as the JDBC DataSource is registered with the app server as being an XA DataSource, and that XADataSource is available in JNDI, [15:33] <gastaldi> oh [15:33] <gastaldi> So the XA part is left to the DataSource then [15:33] <rhauch> gastaldi: and the ModeShape repository is set up to use a JPA source using the XADataSource (found via JNDI) and the system workspace is set up to also use the same or a similarly set up JPA source, [15:33] <rhauch> gastaldi: then it should work just fine. [15:34] <gastaldi> But it should be changed to use JTA as the transaction factory , right ? [15:34] <rhauch> gastaldi: in such a configuration, ModeShape doesn't store any information outside of JDBC, other than the Lucene indexes (which will get updated only upon successful txn commits) [15:34] <gastaldi> ah right, that´s was my doubt [15:35] <rhauch> gastaldi: actually, we'll need to make sure Hibernate is configured correctly (or figure out whether Hibernate can auto-discover the transaction capability of the source) [15:35] <gastaldi> It´s just a matter of configuring 3 properties [15:35] <rhauch> gastaldi: We're actually calling 'EntityTransaction.commit()' or 'rollback()', never calling directly on the connection. [15:35] <gastaldi> right [15:36] <gastaldi> Here is what needs to be added: [15:36] <gastaldi> <property name="current_session_context_class">jta</property> <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property> <property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JBossTransactionManagerLookup</property> [15:37] <gastaldi> the datasource may be XA enabled or not, it does not matter [15:38] <rhauch> gastaldi: we have to do that even if the data source is XA-enabled (and registered)? [15:38] <gastaldi> Yes, it´s transparent to JTA [15:38] <gastaldi> When these properties are set, JTA is used as the underlying transaction [15:39] <gastaldi> and if the Datasource is a XADataSource, it will participate in the transaction in a two-phase commit [15:39] <gastaldi> in other words, it will work fine [15:39] <gastaldi> [15:39] <rhauch> gastaldi: ok. we'll have to figure out what needs to be configurable in the JpaSource then. Maybe just the "TransactionManagerLookup" class ? [15:40] <gastaldi> yes, I think so [15:40] <rhauch> gastaldi: ok. we'll also want to decrease the scope of MODE-1123 [15:40] <jbossbot> jira MODE-1123 Modeshape should support JTA [Open (Unresolved) Enhancement, Major, Unassigned] https://issues.jboss.org/browse/MODE-1123 [15:40] <gastaldi> sure [15:40] <rhauch> gastaldi: because this will only work in some situations
          Hide
          Randall Hauch
          added a comment -

          We should probably add a section in the Reference Guide (perhaps after the Clustering section) that talks about how to use ModeShape with JTA transactions. This should describe the (limited) scope of when this works, how to configure ModeShape, the assumptions that are made (if any), and provide code examples (perhaps an EJB-style with container-managed transactions and explicit calls to UserTransaction).

          Show
          Randall Hauch
          added a comment - We should probably add a section in the Reference Guide (perhaps after the Clustering section ) that talks about how to use ModeShape with JTA transactions. This should describe the (limited) scope of when this works, how to configure ModeShape, the assumptions that are made (if any), and provide code examples (perhaps an EJB-style with container-managed transactions and explicit calls to UserTransaction).
          Hide
          Randall Hauch
          added a comment -

          We'll also have to implement an XAResource for the session (what Chapter 21 of the JSR-283 specification calls an XASession), because per JSR-283 the behavior of Session.save() changes when done within the context of a UserTransaction. For example, graph events shouldn't be fired until the 2nd phase of a 2 phase commit. (Note that the same graph events are used for JCR events, Lucene index updating, and clustering.)

          This will get a little ugly, because right now the connector fires the events to the listener right after it commits the connector's transaction. When JTA is used, this might not really be the end of the global transaction, and so the events will need to be enqueued somehow and fired when the 2nd phase of the commit is started on the Session's XAResource.

          Show
          Randall Hauch
          added a comment - We'll also have to implement an XAResource for the session (what Chapter 21 of the JSR-283 specification calls an XASession), because per JSR-283 the behavior of Session.save() changes when done within the context of a UserTransaction. For example, graph events shouldn't be fired until the 2nd phase of a 2 phase commit. (Note that the same graph events are used for JCR events, Lucene index updating, and clustering.) This will get a little ugly, because right now the connector fires the events to the listener right after it commits the connector's transaction. When JTA is used, this might not really be the end of the global transaction, and so the events will need to be enqueued somehow and fired when the 2nd phase of the commit is started on the Session's XAResource.
          Hide
          Randall Hauch
          added a comment - - edited

          Actually, I just re-read Chapter 21 of the spec, and I didn't recall that workspace-direct methods are also part of the transaction:

          In these discussions we usually assume that operations occur outside the context of transactions; it is assumed that save and other workspace-altering methods immediately effect changes to the persistent layer, causing those changes to be made visible to other sessions.

          This is not the case, however, once transactions are introduced. Within a transaction, changes made by save (or other, workspace-direct, methods) are transactionalized and are only persisted and published (made visible to other sessions), upon commit of the transaction. A rollback will, conversely, revert the effects of any saves or workspace-direct methods called within the transaction.

          We'll have to evaluate this carefully. If we require that the system workspace is also configured to be within a JTA-configured repository source, then the workspace-direct methods might work out okay (really being persisted to the system workspace store only when the transaction is really committed). It looks like events really are going to be the challenge here.

          Show
          Randall Hauch
          added a comment - - edited Actually, I just re-read Chapter 21 of the spec, and I didn't recall that workspace-direct methods are also part of the transaction: In these discussions we usually assume that operations occur outside the context of transactions; it is assumed that save and other workspace-altering methods immediately effect changes to the persistent layer, causing those changes to be made visible to other sessions. This is not the case, however, once transactions are introduced. Within a transaction, changes made by save (or other, workspace-direct, methods) are transactionalized and are only persisted and published (made visible to other sessions), upon commit of the transaction. A rollback will, conversely, revert the effects of any saves or workspace-direct methods called within the transaction. We'll have to evaluate this carefully. If we require that the system workspace is also configured to be within a JTA-configured repository source, then the workspace-direct methods might work out okay (really being persisted to the system workspace store only when the transaction is really committed). It looks like events really are going to be the challenge here.
          Hide
          George Gastaldi
          added a comment -

          Auto generation of Schema should be disabled when JTA is used.

          Show
          George Gastaldi
          added a comment - Auto generation of Schema should be disabled when JTA is used.
          Hide
          Randall Hauch
          added a comment -

          Retargeting to 2.5.0.Final and 2.5.1.GA.

          Show
          Randall Hauch
          added a comment - Retargeting to 2.5.0.Final and 2.5.1.GA.
          Hide
          George Gastaldi
          added a comment -

          I think we should raise the priority of this issue and its subtasks.

          Shane Bryzak is using Modeshape for Seam University and he bumped on this issue, although he could workaround it by using separate transactions, but not a nice solution after all. Maybe the partial support could be sufficient, WDYT ?

          Show
          George Gastaldi
          added a comment - I think we should raise the priority of this issue and its subtasks. Shane Bryzak is using Modeshape for Seam University and he bumped on this issue, although he could workaround it by using separate transactions, but not a nice solution after all. Maybe the partial support could be sufficient, WDYT ?
          Hide
          Jonathan Fields
          added a comment -

          Per Randall's request in MODE-1239, I would like to comment on the importance of this for my work: It is important that Modeshape and the JPA connector be able to "play well" in a Java EE/JBoss AS environment for my use case. That means that it can be used from EJBs with CMT and/or Seam components with Seam Managed Transactions - JTA.

          At the moment I am at the proof of concept stage, and there isn't a technical reason that I need to use the JPA connector. I will investigate the use of either the Disk or Infinispan connectors instead. However, I do expect to encounter some "political" issues in not storing data in an RDBMS, so I may be forced to use the JPA connector in order to take the system from prototype to production, unless I can "sell" the alternative.

          The application in which I am trying to use Modeshape is an evolution of an existing custom content repository using the JBoss stack (Richfaces, Seam, JBoss AS, JPA, JMS, JCA) + Lucene + file system. I am attempting to replace the JPA + Lucene + file system part with JCR. The ability to federate a JPA source with a file system source fits my use case exactly. (I am managing large audio visual files that must be accessible natively.)

          Show
          Jonathan Fields
          added a comment - Per Randall's request in MODE-1239 , I would like to comment on the importance of this for my work: It is important that Modeshape and the JPA connector be able to "play well" in a Java EE/JBoss AS environment for my use case. That means that it can be used from EJBs with CMT and/or Seam components with Seam Managed Transactions - JTA. At the moment I am at the proof of concept stage, and there isn't a technical reason that I need to use the JPA connector. I will investigate the use of either the Disk or Infinispan connectors instead. However, I do expect to encounter some "political" issues in not storing data in an RDBMS, so I may be forced to use the JPA connector in order to take the system from prototype to production, unless I can "sell" the alternative. The application in which I am trying to use Modeshape is an evolution of an existing custom content repository using the JBoss stack (Richfaces, Seam, JBoss AS, JPA, JMS, JCA) + Lucene + file system. I am attempting to replace the JPA + Lucene + file system part with JCR. The ability to federate a JPA source with a file system source fits my use case exactly. (I am managing large audio visual files that must be accessible natively.)
          Hide
          Randall Hauch
          added a comment -

          This should be significantly easier with the 3.0 architecture, since Infinispan already can participate within JTA transactions. The only changes we will have to make will be to add an XASession that should be created when the 'Repository.login(...)' methods are called from within an active transaction. In this case, the XASession should register itself with the transaction so that it can receive notifications of the different phases, and participate accordingly. The XASession's save() behavior will be a bit different, especially w/r/t firing the events.

          Show
          Randall Hauch
          added a comment - This should be significantly easier with the 3.0 architecture, since Infinispan already can participate within JTA transactions. The only changes we will have to make will be to add an XASession that should be created when the 'Repository.login(...)' methods are called from within an active transaction. In this case, the XASession should register itself with the transaction so that it can receive notifications of the different phases, and participate accordingly. The XASession's save() behavior will be a bit different, especially w/r/t firing the events.
          Hide
          Randall Hauch
          added a comment -

          Marking as WONTFIX, since this will not be done on the 2.x codebase. Instead, transaction support in 3.x is represented by MODE-1498.

          Show
          Randall Hauch
          added a comment - Marking as WONTFIX, since this will not be done on the 2.x codebase. Instead, transaction support in 3.x is represented by MODE-1498 .

            People

            • Assignee:
              Unassigned
              Reporter:
              George Gastaldi
            • Votes:
              3 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: