I have a big struggle integrating our tx file store as well as the tx cache into Slide. While problems with store and cache in themselves are under control, the glue between them and Slide causes trouble.
Especially in concurrent scenarios I experience problems.
Maybe someone can help by commenting on the observations about stores I made and either confirm or contradict (in this case I'd prefer contradiction):
CHILDREN STORES
1. All store implementations subclassing AbstractSimpleService are merely toy, as they can only be part in no more than a single transaction simultaneously: - FileContentStoreNoVersioning - FileDescriptorsStoreNoVersioning - JDBCStore, JDBCContentStore and JDBCDescriptorsStore including Cloudscape, MySQL and Oracle implementations
2. Stores subclassing AbstractService do not have this limitation: - FileContentStore - XMLFileDescriptorsStore - MemoryDescriptorsStore
3. Stores subclassing AbstractXAService and indirectly AbstractServiceBase leave the implementation of XAResource to subclasses and thus do not have this limitation. Implementing subclasses: - slidestore.j2ee.J2EEStore - org.apache.slide.store.impl.rdbms.J2EEStore - AbstractTxFileStoreService subclassed by TxFileContentStore and TxXMLFileDescriptorsStore
4. org.apache.slide.store.impl.rdbms.J2EEStore seems to be an updated version of slidestore.j2ee.J2EEStore. However they differ in the following respects: - org.apache.slide.store.impl.rdbms.J2EEStore implements all store interfaces and deleagates store access to a configurable adapter while slidestore.j2ee.J2EEStore does this to its subclasses J2EEDescriptorsStore and J2EEContentStore - database schema is is different while org.apache.slide.store.impl.rdbms.J2EEStore is very superior
5. Conclusion: The only public production quality store is org.apache.slide.store.impl.rdbms.J2EEStore which its standard adapter implementation StandardRDBMSAdapter. - Stores listed under (1) are unfit because they do not support concurrent requests. - Stores listed under (2) are unfit because they do not provide transactional support. This may lead to inconsistencies much more quickly than one might think - our tx file store (TxFileContentStore and TxXMLFileDescriptorsStore ) is unfit as it is not stable, yet, although not less stable than stores listed under (2). It also has performance limitations that are very hard to overcome. Especially search for properties will be very slow. Also transactionality comes at a certain price when writing, while reading should be pretty fast.
MAIN STORES
Another confusing thing is the relation between AbstractStore and StandardStore on one side and the stores named above on the other side. While both implement the interface of child stores like ContentStore, NodeStore, etc. they differ in use. StandardStore is the central access point for persistence and delegates all calls to configurable underlying child stores as named above. At the beginng of every access concerned stores are enlisted in the global transaction and delisted at the end. Depending on the state of the store their participation in the transaction is either suspended or ended with failure.
Even though StandardStore implements all the XAResource methods it is never part of any transaction.
Thus caching can not underly transactional control. Because of this,
there is a workaround that clears caches as soon as any child store is
delisted with failure in any transaction. This means on one hand there
can be invalid cached data temporarily available for all transactions
and on the other hand that valid data mighly be overly invalidated
without need. Obviously, transactions that get rolled back, will not also invalidate caches in StandardStore, which is even worse.
Likewise as StandardStore might be called concurrently by multiple requests it needs to be thread safe. Even though there is no synchronisation, StandardStore itself can be actually considered thread safe. However, as calls are delegated to child stores, these must be guaranteed to be thread safe as well.
Of the stores that support multiple transactions at least XMLFileDescriptorsStore is not thread safe. There may be more examples, but an obvious one is in method XMLFileDescriptorsStore.retrieveObject. While calling this method a concurrent call to XMLFileDescriptorsStore.removeObject might invalidate UriProperties by calling removeObject and setting object to null. This might happen exactly between the final null check in AbstractUriProperties.retrieveObject called by return aProps.retrieveObject in XMLFileDescriptorsStore.retrieveObject and the actual return in this class.
You may say, this is very unlikely? Maybe, but who can live with a store return invalid stuff in a nondeterministic way? By the way, when running the test suite provided by the people from Software AG (BIG THANKS TO THEM FOR SUCH A GOOD WORK) using this store you might actually see exactly this happen in the concurrent tests.
(As a side note: This is a thing I forgot in the current version of the tx file store as well. I fixed this in my local copy and will offer it for commit as soon as I mastered the remaining problems.)
Sorry for reading this lengthy post and BIG THANKS for comments in advance, Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
