Thanks Mike

There is no fix because this is testing a condition that we haven't previously had a test for.

There was an issue with the test which I fix with commit f6a9f949b3d01e7dc587d2a25eb0cb9fb6cabd20. The following job

http://172.17.131.2/view/Narayana+BlackTie/job/narayana-java6/1170

shows the test passing so I am moving the jira back to resolved.

Mike,

This might not be resolved yet. See:

http://172.17.131.2/view/Narayana+BlackTie/job/narayana-java6/1168/

However, looking at the change log for the run, you can see that it's only the test that was added and not the fix.

The resolution includes a test:

com.hp.mwtests.ts.arjuna.objectstore.AltStoreTest

and a doc update:

https://github.com/jbosstm/documentation/blob/master/docs/development_guide/en-US/Configuration_Options.xml

Thanks Mike, I presume you have confirmed nothing is created on disk in that scenario? Perhaps your resolution could be to update the documentation in the ArjunaCore programmers guide (or wherever it is we document ObjectStores) in the github (head/trunk/master whatever you want to call it) version. Note, do not add it to the documentation under docs/ as that is platform docs and this ObjectStore feature is not supported in EAP

It's actually three stores rather than four, since the recovery store is not a separately configurable entity, it's just an internal api alias for obtaining the action store.

The problems here stem from trying to retrofit a 'multiple instances of any given environment bean type' model onto a config system that previously assumed each was a singleton. The current semantic of the unnamed getters xPropertyManager.getFooBean() is 'get the instance called 'default', NOT 'get an abstract instance that contains the defaults for all other instances'. Indeed such defaults are not globally configurable at all - they are hardcoded. Thus it's not currently possible to e.g. change the store dir for all three stores with a single config option. Rather, you have to set it explicitly for each of the three store instances. This is by design and is not a bug.

Ultimately the problems stem from not wanting to depend on a full DI framework, which limits the ability to inject named bean instances cleanly. The wider issue will need to be rethought as part of the 'removing statics / allowing dynamic reconfig / multiple cohabiting TMs' work. Meanwhile I'd favour more clearly documenting the current semantic over changing it, as the latter approach risks causing confusion and breaking existing configs.

XTS writes both coordinator and participant recovery records to the recovery store obtained by calling StoreManager.getRecoveryStore(). I don't believe changing the config to use an in-memory store raises any special difficulties as far as XTS is concerned – other than the fact that the coordinator and participant web service may not reside in the same JVM/on the same host (i.e. there may be more than one store in play which you might need to reconfigure).

Firstly some background. It is possible to configure different stores for different purposes. Each store is a singleton so each store type is shared.

We currently use at least four stores (XTS uses some others):

• an action store for transaction and participant logs;
• a recovery store (which defaults to the action store);
• a state store for use with TxOj and is not used with JTA (or JTS);
• a communications store for storing connectivity information such as ORB endpoints or transaction manager status items.

Calling arjPropertyManager.getObjectStoreEnvironmentBean() looks up the default store and is equivalent to:
BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "default") and is used to configure the action store.

The other stores can be configured by looking up a specific named ObjectStoreEnvironmentBean.
Use "default" or "stateStore" to configure the action and state stores respectively.
Use "communicationStore" to configure the communications store.

So the actual bug/feature is that looking up the default store environment bean via the properties manager (arjPropertyManager.getObjectStoreEnvironmentBean()) should return a bean that will configure all stores. Howeve this could be risky (for example it could interfere with XTS behaviour) so my preference would be to force the user to be specific about which stores he wants an environment bean for by making the getObjectStoreEnvironmentBean call take the store name as a parameter. But that leaves the difficult issue of how to specify which store to use in the properties file
<entry key="ObjectStoreEnvironmentBean.objectStoreType">XYZStore</entry>
since this entry is only applied to the default store.

We could simply document the behaviour in jbossts-properties.xml and tell users to explicitly set the communications store programatically if required.
So the communications store type would have to be set as follows:

BeanPopulator.getNamedInstance(ObjectStoreEnvironmentBean.class, "communicationStore").setObjectStoreType(com.arjuna.ats.internal.arjuna.objectstore.VolatileStore.class.getName());

Is this latter approach acceptable to all concerned?