[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1137: ------------------------------------- Suggested design. This will be experimental in the first release. Enabling/disabling it can be done through the following configuration element: {code:xml} <transaction lockingSingleNode="true"/> {code} As this will be implemented after ISPN-1131, which is experimental as well, *lockingSingleNode* would only be available when *lockAtPrepareTime*="true". If *lockAtPrepareTime*="false" and *lockingSingleNode*="true" a warning is logged to the user. Also *lockingSingleNode* only makes sense for distributed caches. In the case the cache runs in replicated mode it is ignored. Both local and remote locks are being acquired during prepare time in {{PrepareTimeLockingInterceptor.visitPrepareCommand}}: {code:java} @Override public Object visitPrepareCommand(TxInvocationContext ctx, PrepareCommand command) throws Throwable { super.visitPrepareCommand(ctx, command); if (ctx.isOriginLocal()) { for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } } return invokeNextInterceptor(ctx, command); } {code} The method {{acquireLock(WriteCommand)}}, as described in ISPN-1131, will be enhanced to only acquire locks on the key(s) pertaining to the {{WriteCommand}} if the key{s} have as main data owner the node where the code executes. A node *N* is defined as a main data owner of a key *k* if {{consistentHash(k).get(0)==N}}. Handling failure situations: if a node on which a remote lock is acquired fails between after prepare and before commit, the prepare will be re-run on the new main data owner and only then committed (this was introduced together with ISPN-1049). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-1137 at 5/24/11 5:10 PM: -------------------------------------------------------------- Suggested design. This will be experimental in the first release. Enabling/disabling it can be done through the following configuration element: {code:xml} <transaction lockingSingleNode="true"/> {code} As this depends on implementing ISPN-1131, which is experimental as well, *lockingSingleNode* is only available when *lockAtPrepareTime*="true". If *lockAtPrepareTime*="false" and *lockingSingleNode*="true" a warning is logged to the user. Also *lockingSingleNode* only makes sense for distributed caches. In the case the cache runs in replicated mode the configuration is ignored. Both local and remote locks are being acquired during prepare time in {{PrepareTimeLockingInterceptor.visitPrepareCommand}}: {code:java} @Override public Object visitPrepareCommand(TxInvocationContext ctx, PrepareCommand command) throws Throwable { super.visitPrepareCommand(ctx, command); if (ctx.isOriginLocal()) { for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } } return invokeNextInterceptor(ctx, command); } {code} The method {{acquireLock(WriteCommand)}}, as described in ISPN-1131, will be enhanced to only acquire locks on the key(s) pertaining to the {{WriteCommand}} if the given key{s} have as main data owner the node where the prepare executes. A node *N* is defined as a main data owner of a key *k* if {{consistentHash(k).get(0)==N}}. Interference with non transactional operations is also a concern, as in its current form, a non transactional operation would acquire and apply a change on non-owners disregarding the lock on the main data owner. To avoid this situation, non-transactional operations will be transparently wrapped within a transaction. This approach two significant side effects: * the regular operations would be more costly because they now happen in 2 phases, ie 2 RPCs * solves problem #2, as described in the [PossibleLockingImprovements|http://community.jboss.org/wiki/PossibleLocki...] document Handling failure situations: if a node on which a remote lock is acquired fails between prepare and before commit, the prepare is re-run on the new main data owner and only then committed (this was introduced together with ISPN-1049). was (Author: mircea.markus): Suggested design. This will be experimental in the first release. Enabling/disabling it can be done through the following configuration element: {code:xml} <transaction lockingSingleNode="true"/> {code} As this depends on implementing ISPN-1131, which is experimental as well, *lockingSingleNode* is only available when *lockAtPrepareTime*="true". If *lockAtPrepareTime*="false" and *lockingSingleNode*="true" a warning is logged to the user. Also *lockingSingleNode* only makes sense for distributed caches. In the case the cache runs in replicated mode the configuration is ignored. Both local and remote locks are being acquired during prepare time in {{PrepareTimeLockingInterceptor.visitPrepareCommand}}: {code:java} @Override public Object visitPrepareCommand(TxInvocationContext ctx, PrepareCommand command) throws Throwable { super.visitPrepareCommand(ctx, command); if (ctx.isOriginLocal()) { for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } } return invokeNextInterceptor(ctx, command); } {code} The method {{acquireLock(WriteCommand)}}, as described in ISPN-1131, will be enhanced to only acquire locks on the key(s) pertaining to the {{WriteCommand}} if the given key{s} have as main data owner the node where the prepare executes. A node *N* is defined as a main data owner of a key *k* if {{consistentHash(k).get(0)==N}}. Handling failure situations: if a node on which a remote lock is acquired fails between prepare and before commit, the prepare is re-run on the new main data owner and only then committed (this was introduced together with ISPN-1049). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1137: ------------------------------------- Paul Romano suggested a scenario that would cause inconsistencies: N3: receives T1, acquires lock on c, reply positively to the prepare to N1 N3: receives T2, blocks on lock acquisition on c N1: receives positive reply on reply for T1, broadcasts commit message for T1 to N3, N4 .... but the message to N4 gets delayed ... N3: receives commit message for T1, writes back c<-T1, unblocks T2, replies positively for T2' s prepare to N2 N2: receives positive reply on reply for T2, broadcasts commit msg for T2 to N3, N4 N4: receives commit message for T2 (before that for T1), writes back c<-T2 N4: receives commit message for T1, writes back c<-T1, N3: receives commit message for T2, writes back c<-T2 and in the end N3,N4 apply in different order the writes on c, ending up in inconsistent states (N3 has c=T2, N4 has c=T1). In order to fix this, you could force causality order in the delivery of the commit messages (that trigger the writeback), which could be trackable using vector clocks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Mircea Markus edited comment on ISPN-1137 at 6/17/11 5:27 AM: -------------------------------------------------------------- Suggested design. This will be experimental in the first release. Enabling/disabling it can be done through the following configuration element: {code:xml} <transaction lockingSingleNode="true"/> {code} As this depends on implementing ISPN-1131, which is experimental as well, *lockingSingleNode* is only available when *lockAtPrepareTime*="true". If *lockAtPrepareTime*="false" and *lockingSingleNode*="true" a warning is logged to the user. Also *lockingSingleNode* only makes sense for distributed caches. In the case the cache runs in replicated mode the configuration is ignored. Both local and remote locks are being acquired during prepare time in {{PrepareTimeLockingInterceptor.visitPrepareCommand}}: {code:java} @Override public Object visitPrepareCommand(TxInvocationContext ctx, PrepareCommand command) throws Throwable { super.visitPrepareCommand(ctx, command); if (ctx.isOriginLocal()) { for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } } return invokeNextInterceptor(ctx, command); } {code} The method {{acquireLock(WriteCommand)}}, as described in ISPN-1131, will be enhanced to only acquire locks on the key(s) pertaining to the {{WriteCommand}} if the given key{s} have as main data owner the node where the prepare executes. A node *N* is defined as a main data owner of a key *k* if {{consistentHash(k).get(0)==N}}. Interference with non transactional operations is also a concern, as in its current form, a non transactional operation would acquire and apply a change on non-owners disregarding the lock on the main data owner. Manik suggested an approach similar to then one used in JSR-107: 1) If a cache is non-transactional, transactional threads accessing the cache throw an exception. 2) If a cache is transactional, threads must have an ongoing transaction. If not, an exception is thrown, unless: 3) Auto-commit is configured to be true. In this case, if a non-transactional thread accesses the cache, a tx is started, work done, and the tx auto-committed. Handling failure situations: if a node on which a remote lock is acquired fails between prepare and before commit, the prepare is re-run on the new main data owner and only then committed (this was introduced together with ISPN-1049). was (Author: mircea.markus): Suggested design. This will be experimental in the first release. Enabling/disabling it can be done through the following configuration element: {code:xml} <transaction lockingSingleNode="true"/> {code} As this depends on implementing ISPN-1131, which is experimental as well, *lockingSingleNode* is only available when *lockAtPrepareTime*="true". If *lockAtPrepareTime*="false" and *lockingSingleNode*="true" a warning is logged to the user. Also *lockingSingleNode* only makes sense for distributed caches. In the case the cache runs in replicated mode the configuration is ignored. Both local and remote locks are being acquired during prepare time in {{PrepareTimeLockingInterceptor.visitPrepareCommand}}: {code:java} @Override public Object visitPrepareCommand(TxInvocationContext ctx, PrepareCommand command) throws Throwable { super.visitPrepareCommand(ctx, command); if (ctx.isOriginLocal()) { for (WriteCommand wc : command.getModifications()) { acquireLock(wc); } } return invokeNextInterceptor(ctx, command); } {code} The method {{acquireLock(WriteCommand)}}, as described in ISPN-1131, will be enhanced to only acquire locks on the key(s) pertaining to the {{WriteCommand}} if the given key{s} have as main data owner the node where the prepare executes. A node *N* is defined as a main data owner of a key *k* if {{consistentHash(k).get(0)==N}}. Interference with non transactional operations is also a concern, as in its current form, a non transactional operation would acquire and apply a change on non-owners disregarding the lock on the main data owner. To avoid this situation, non-transactional operations will be transparently wrapped within a transaction. This approach two significant side effects: * the regular operations would be more costly because they now happen in 2 phases, ie 2 RPCs * solves problem #2, as described in the [PossibleLockingImprovements|http://community.jboss.org/wiki/PossibleLocki...] document Handling failure situations: if a node on which a remote lock is acquired fails between prepare and before commit, the prepare is re-run on the new main data owner and only then committed (this was introduced together with ISPN-1049). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1137: -------------------------------- Description: Detailed here http://community.jboss.org/wiki/SingleNodeLockingModel As without ISPN-1131 locks are being acquired as the transaction progresses this optimization makes more sense after having ISPN-1131 in place. was: Detailed here, as the 4th improvement: http://community.jboss.org/wiki/PossibleLockingImprovements As without ISPN-1131 locks are being acquired as the transaction progresses this optimization makes more sense after having ISPN-1131 in place. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1137: ---------------------------------------- Mircea, following on what you said in http://community.jboss.org/thread/170702?tstart=0, make sure replicated caches are also tested, i.e. replicated counter concurrent update in two nodes with REPL_SYNC enabled. This could be important to make the current HotRod topology work better under concurrent update scenarios. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1137: ----------------------------------- Fix Version/s: 5.1.0.BETA1 (was: 5.1.0.ALPHA2 ) As talked earlier, moving to Beta1. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1137: ----------------------------------- Fix Version/s: 5.1.0.BETA3 (was: 5.1.0.BETA2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1137?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1137: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/574 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira