The current limitations are explained more in detail in the known issue section.
Lock cache loader dialect setup
The cache loader persistence of the lock manager configuration should not require the declaration of a dialect. The latest JCR release has dialect auto detection and so should have the cache loader (otherwise that makes the JCR dialect auto detection pointless as manual setup is stil required).
Database type problem
The cache loader requires the setup of database types which are not the same (blobs). For instance for HSQLDB the jbosscache-cl-cache.jdbc.node.type=OBJECT needs to be set and for other database, the value changes (see here for more information http://community.jboss.org/wiki/JDBCCacheLoader). The correct database type should be configured by the dialect auto detection. For instance a special property could be setup and replaced in the lock managed jboss cache configuration xml file. The identified database types are
- jbosscache-cl-cache.jdbc.node.type (the one raising issues)
- jbosscache-cl-cache.jdbc.fqn.type (shoudl be ok but would be safer to be setup by the auto detector)
When no transaction manager is found, the JBossCacheWorkspaceStorageCache uses a constructor that calls the default constructor with a null value that leads to a NullPointerException:
Caused by: java.lang.NullPointerException at org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.JBossCacheWorkspaceStorageCache.<init>(JBossCacheWorkspaceStorageCache.java:270) at org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.JBossCacheWorkspaceStorageCache.<init>(JBossCacheWorkspaceStorageCache.java:300)
TransactionService and TransactionManagerLookup
It is not clear what should be the scope of the TransactionService and TransactionManagerLookup services. For now they are configured at the portal container scope. Should it be instead shared between the various instance as usually the transaction manager is unique in the application server?