That class makes more sense now, but I think I've been asking the wrong question. I think what I should have been asking is this: How do I create multiple transaction-aware sessions dynamically (as in, within the code)?
Based on what you've said, and what I've read in the code and documentation, would something like the following code work? What I'm hoping is that each of the sessions created in this process will be tied to the same transaction, so that any session.save() calls defer writing to the repository until the transaction is committing.
Code:
public List<Object> doSomethingInRepository( List<String> workspaces, Object param )
{
List<Object> results = new LinkedList<Object>();
for( String workspace : workspaces )
{
// Get credentials initialized someplace.
Credentials creds = getCredentials();
// Get repository from Spring dependency injection; probably a
// JndiObjectFactoryBean that returns the raw javax.jcr.Repository
Repository repository = getRepository();
JcrSessionFactory jsf =
new JcrSessionFactory( repository, workspace, creds );
TransactionAwareRepository txRepository =
new TransactionAwareRepository();
txRepository.setAllowCreate( false );
txRepository.setAllowNonTxRepository( false );
txRepository.setTargetFactory( jsf );
txRepository.afterPropertiesSet();
JcrTemplate jcrTemplate = new JcrTemplate( jsf );
// Get the JCR Dao object that was configured with Spring dependency
// injection.
getMyJcrDao().setJcrTemplate( jcrTemplate );
results.add( getMyJcrDao().doSomethingInWorkspace( param ) );
}
return( results );
}
In my app, the Credentials and Repository instances will be the same all the time, so they'll probably be configured with dependency injection. Some of my DAO classes will only want to deal with a single workspace and I'll be able to wire them as you described. But any DAO class related to data stored in a user-owned workspace will need to be able to handle accessing one or more of those workspaces in a single transaction, with everything done in with all the workspaces (reading and writing) covered by the same transaction; I won't be able to wire those classes at all.
Also, something unrelated to my question: looking at how the other classes work, it might be nice to have a constructor for TransactionAwareRepository that allows the allowCreate, allowNonTxRepository, and targetFactory to be set (and then calls afterPropertiesSet automatically).
Questions about SpringModule's JCR implementation
Originally Posted by costin
