3

I am using Jackrabbit with datastore and a separate database for the rest of my data. I have deployed Jackrabbit JCA to JBoss 7.1.1. I have debugged the application and I see that the session instance is of type XASessionImpl.

I am currently getting a session like this:

    final Credentials credentials = new SimpleCredentials("admin", "admin".toCharArray());

    try {
        final Session session = repository.login(credentials);
        return session;
    } catch (RepositoryException e) {
        throw new RuntimeException(e);
    }

I invoke session.save(); and then session.logout() when I am done each time I access it. Is this correct when it is part of a global transaction. I do not have much knowledge about distributed transactions etc so please correct me if I am wrong. I tried to throw a runtime exception inside one of my methods that is annotated with @Transactional (using Spring 3.2), but the data in the datastore is not removed. Is this correct? Doesn't data that is being added in the data store removed if the transaction is rolled back? My "testing" enviroment for this was: add content to Jackrabbit, then to database and then throw runtime exception. Or isn't Jackrabbit configured correctly?

BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
LuckyLuke
  • 47,771
  • 85
  • 270
  • 434

1 Answers1

0

Jackrabbit is probably running its own transaction, assuming the Spring-managed transaction is rolled back but the content in the datastore remains. How does your Spring/JBoss resource configuration look like?

Some quick Googling (with keywords JTA Jackrabbit Spring JBoss) reveals that setting up XA transactions with Jackrabbit and an XA JDBC DataSource might be easier said than done. Old mailing list entries report being able to use a JTA transaction manager called Jencks to do this, but Jencks' development appears since to have been discontinued.

Also have a look (though with a grain of salt) at section 1.2.3 in this JBoss community wiki page that states that "jackrabbit implements the XA protocol internally and requires a non-XA datasource underneath", which implies the behavior you're seeing.

Also, as an option to XA, have you considered emulating XA like this (mind the pseudo-code)?:

@Transactional
public void addContent() {
    try {
        storeContentInJcrRepo();
        saveMetadataInDatabase();
    catch (DataAccessException e) {
        deleteNewlyStoredContentFromJcrRepo();
        // Rethrow to ensure DB transaction is rolled back
        throw e;
    }
}
Jukka
  • 4,583
  • 18
  • 14