While this is sounds trivial to do, it is a lot more complicated than it sounds.
When you redeploy the datasource it has lost track of the transaction context.
e.g.
// Begin Transaction here
// Before redeploy
Connection c1 = dataSource.getConnection();
// Use it
c1.close();
// Redeploy here
// After redeploy
Connection c2 = dataSource.getConnection();
// etc.
// End Transaction here
Normally (without the redeploy) c2 would have the same underlying connection as c1
and would share the same jdbc transaction.
With the redeploy, it is two different real connections and unless it is XA two different
jdbc transactions.
So for at least a local-tx-datasource the semantics are broken.
To be really "atomic" it would have to somehow pass-off both the real
connections from one pool to another
and the connection manager state for those connections as the redeploy occurs.
This "passing off" of connections and state may not even be valid if you are
redeploying
the datasource to change a policy decision.
But this could be dealt with by "immediately" closing those passed off
connections
when the application finishes with them (i.e. under the old policy)
and creating new ones with the new policy.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4128679#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...