There's no locking, so there might be some interference when accessing the same file system.
I presume the file would be on a shared disk which would be mounted on each of the servers in the cluster? Most network file systems don't have proper locking support.
Correct, I am planning to use a shared Solaris NFS drive to use as the shared filesystem. What I am trying to figure out is if I can reliably get optimistic locking to work between different nodes in a cluster.
For example, we have optimistic locking enabled with the following situation:
Node A gets a copy of the tree node and prepares to write some data into the cache.
Meanwhile, Node B gets a copy also and writes its changes before Node A does.
What I want to know, is what will Node A do? Will it fail/rollback? Can its internal version for the GlobalTransaction be smart enough to know that Node B wrote some changes before it.
Any help would be appreciated.
The tx on node A will fail and rollback *provided* the tx on node B completes before node A starts to commit. If node A is already in it's prepare phase and node B broadcasts a commit, both txs will fail (node B unable to successfully prepare on node A, and node A unable to successfully prepare on node B)
Internal versioning is on the node (as in, node in the tree structure) level. And this version info is replicated when modifications are replicated so this is consistent across a cluster.
Thanks for the reply. Will this work without a JTA TransactionManager? I am planning to deploy the clusted nodes in Tomcat and do not have access to an app server JTA TransactionManager.
You need a JTA TM if you want to use optimistic locking. There are several standalone, open src JTA TMs that run in tomcat - have a look at JBoss Transactions, for example.