Just a followup: After some more experimenting, I was able to get transactions working properly by using manual enlistment of the JCR Session (which in the JackRabbit case is also an XAResource). Rather than forcing higher-level code to have knowledge of the jackrabbit session, it seemed better to add a new, optional method to the FedoraStoreSession interface: getXAResource(). If supported by the underlying store, callers can enlist Fedora in a transaction (possibly distributed) while working with the FedoraStoreSession. The transaction test in github now works, and uses this technique.
As far as transaction support goes, this seems sufficient for now, but I would like to eventually look into what it would take to have a JCA (Java Connector Architecture) adapter or a PlatformTransactionManager so that enlistment of fcrepo-store sessions could happen more auto-magically and work with Spring-style transaction management (declarative or programmatic). - Chris On Wed, Mar 28, 2012 at 4:10 PM, Chris Wilper <cwil...@duraspace.org> wrote: > Hi all, > > Just wanted to update you on most recent developments in the > fcrepo-store experiments: > > 1) I changed the API to be session-oriented so impls can delegate to > underlying sessions/connections more efficiently. For example, the > AkubraFedoraStoreSession impl delegates to injected instance-wide > BlobStoreSessions rather than allocating new sessions on a per-request > basis. > 2) I added a JCR impl and tested with Jackrabbit: > http://cwilper.github.com/fcrepo-store/apidocs/com/github/cwilper/fcrepo/store/jcr/JCRFedoraStore.html > > As mentioned before, I think the main benefit of having a JCR-based > Fedora storage layer impl is that if the configured JCR impl is > transactional and we're using it to store all repository state (Fedora > objects and managed datastreams), it makes it much easier to expose > Fedora itself as a transactional resource. > > With that goal in mind, I started some test code to see how > programmatic transaction management might be done with > fcrepo-store-jcr: > > https://github.com/cwilper/fcrepo-store/blob/master/fcrepo-store-jcr/src/test/java/com/github/cwilper/fcrepo/store/jcr/JCRFedoraStoreTransactionTest.java > > Unfortunately, I haven't been successful yet. Both existing > transaction tests (both using Atomikos and via Spring) fail to > actually roll back, which makes me think the JCR session somehow isn't > really participating in the transaction. > > What I'd really like to have is a way to control transaction > boundaries in code that sits atop an fcrepo-store impl, without regard > to the particular JCR or other underlying transactional resource > that's in use. Using straight JTA (UserTransaction, as indicated in > the JCR spec) would seem to be the way forward, but actual working > examples with Jackrabbit (or any other open source JCR impl) have been > hard to come by. > > - Chris ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Fedora-commons-developers mailing list Fedora-commons-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
