transaction and replication in one application

[mica]

Hi All,

I was trying to modify same node from two different applications using replicated CacheTree. Each application starts its own transaction and in this transaction tries to modify the node. Isolation level is set to SERIALIZABLE mode so I hoped that one of applications would be blocked until the end of second transaction. It doesn't.
Similar scenario is implemented in SyncReplTXTest, although there everything is performed in one process.
I was trying to use DummyTransactionManager and JOTM (each process runs its own copyinstance of the manager).
Is it possible to realize such scenario?
Has anyone realized it?
Or maybe it is necessary to have only one instance of TM for all JVM's?

--
thx,
Michal

[belaban]

There's a unit test that tests SERIALIZBLE, please run it first to check whether this works with JOTM

[mica]

could you specify which unit test do you mean? You use SERIALIZABLE mode in most unit tests.

[belaban]

ConcurrentTransactionalTest is one of them, but I guess there are more.

[mica]

ConcurrentTransactionalTest uses Local CacheMode and I'm more concerned about replication. SyncReplTXTest also uses SERIALIZABLE mode, but it runs both TreeCache from the same process. What I'm trying to do is to perform similar test, but with two TreeCache in different processes.

It seems, that if I run it with JOTM obtained through JNDI it doesn;t work. Namely what I do is:

1) Without any explicit transaction in process A put value "1" for key "a".

2) Start transaction in process A, modify key "a" and wait.

3) Start process B and obtain value for key "a", which appears to be null.

4) Start transaction in process B and modify key "a".

If I understand the problem well, both steps 3 and 4 should wait until the transaction in process A ends. And of course obtaining value from "a" should not return null.
Of course without transactions cache replicates correctly.
Can it be a problem with cache?

[belaban]

Yes, with isolation level SERIALIZABLE, B should wait accessing "a" (either read or write) until A completes. There are unit tests that do exactly that, also for the replicated case. Look under org.jboss.cache.replicated.

If you don't find one, it would be nice if you could submit a unit test that shows the problem.