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