This comment was posted by Bela Ban on jboss-group mailing list. I'm reposting it here to facilitate discussion.
> For JBoss clustering, we've been trying to avoid
> having the remote client use JavaGroups. This is
> because the client must be a member of the
> Group/Channel to do anything. Maybe this has
> changed in the current version of JG. Sacha? Bela? >comments?
JavaGroups can be configured to use a 'services' architecture where there are 2 groups: a lightweight client-group, in which all clients and one or more servers are member, and a server-group in which only the
servers are members. Clients use the client-group to talk to a server, which in turn uses the server-group, e.g. to replicate.
However, as mentioned in my prev email, there are issues, e.g.:
* Great number of clients, and/or clients not necessarily in the same multicast enabled network
* Clients don't need to talk to each other, don't need to know about each other (e.g. no need to get notified when a new client joins/leaves/crashes).
I'd suggest using JavaGroups for server-server communication, not client-server comm (although the latter is supported as well).
this is additional data.
1st MDB program
1-1. UserTransaction begin
1-2. update DB
1-3. send queue (2nd MDB)
1-4. UserTransaction commit
2nd MDB program
2-1. UserTransaction begin
2-2. read DB which was updated from 1-2
2-3. update DB
2-4. send queue (2nd MDB)
2-5. UserTransaction commit
2-2 does not read 1-2 data....
but It had succeeded, when JTA was not used.
and more info.
This problem is generated when JTA manages 2 JDBCConnections and 1 JMSConnection .
However, this problem is not generated when JTA manages 1 JDBCConnection and 1 JMSConnection .
Is it the problem of Oracle?