Re: [infinispan-dev] boolean properties in config
On Dec 12, 2011, at 3:45 AM, Mircea Markus wrote: On 10 Dec 2011, at 10:04, Pete Muir wrote: https://issues.jboss.org/browse/ISPN-1474 Currently we do a mix of: enableXXX() disableXXX() enabled(boolean b) XXX(boolean b) where XXX is something to enable or disable (e.g. purgeOnStartup). We also the scatter the word use around in a very inconsistent fashion. this is a bit ugly indeed +1 I would like to rationalise this, and would propose that every boolean has: enableXXX disableXXX xxxEnabled(boolean b) The former 2 are nice for hardcoded config, the latter is nice when you are adapting one format to another (e.g. Paul). I think this would be much more readable. My only comment is that we allow two ways of doing the same thing, which might be slightly confusing for the users. Also the easiness of migration from old to new configuration is important, but IMO not as important to make the new config simple. I agree with Mircea that having two ways of doing the same thing might confuse users. If I had to choose I'd probably go for the latter option. I would deprecate the usage of XXX(boolean b) and useXXX(boolean b) and remove in 6. Thoughts? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] New partial replication protocol providing serializability guarantees in Infinispan
I think Manik is referring to the fact that ISPN's MVCC implementation does not guarantee serializability. yes. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Some flags are incompatible with implicit transactions
Hi all, Re: https://issues.jboss.org/browse/ISPN-1556 Re: https://github.com/infinispan/infinispan/pull/719/files#r288994 The fix I suggest works well with explicit transactions, but if we leave this as is, implicit txs might leak transactions. The reason is because if we allow a put with FAIL_SILENT which fails with an implicit tx, then the tx won't be committed nor removed from tx table. But, does FAIL_SILENT make sense with implicit tx? Well, it doesn't. The point of FAIL_SILENT is to avoid a failure rollbacking a tx and being noisy. So, it implies that there's a bigger, external, transaction within which this operation is called. And it's not just FAIL_SILENT, there're other flags do not make sense with implicit transactions, such as FORCE_WRITE_LOCK: /** * Forces a write lock, even if the invocation is a read operation. Useful when reading an entry to later update it * within the same transaction, and is analogous in behavior and use case to a ttselect ... for update ... /tt * SQL statement. */ So, I think my fix is right here, but what we really need is it's a way to stop people from using certain flags with implicit transactions. Here's my (quickly thought) list: FORCE_WRITE_LOCK FAIL_SILENTLY PUT_FOR_EXTERNAL_READ Any others? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] boolean properties in config
On Tue, Dec 13, 2011 at 10:44 AM, Galder Zamarreño gal...@redhat.com wrote: On Dec 12, 2011, at 3:45 AM, Mircea Markus wrote: On 10 Dec 2011, at 10:04, Pete Muir wrote: https://issues.jboss.org/browse/ISPN-1474 Currently we do a mix of: enableXXX() disableXXX() enabled(boolean b) XXX(boolean b) where XXX is something to enable or disable (e.g. purgeOnStartup). We also the scatter the word use around in a very inconsistent fashion. this is a bit ugly indeed +1 I would like to rationalise this, and would propose that every boolean has: enableXXX disableXXX xxxEnabled(boolean b) The former 2 are nice for hardcoded config, the latter is nice when you are adapting one format to another (e.g. Paul). I think this would be much more readable. My only comment is that we allow two ways of doing the same thing, which might be slightly confusing for the users. Also the easiness of migration from old to new configuration is important, but IMO not as important to make the new config simple. I agree with Mircea that having two ways of doing the same thing might confuse users. If I had to choose I'd probably go for the latter option. How about: xxxEnabled() xxxEnabled(boolean b) However, I don't think enabled is going to work in every situation (loader.sharedEnabled?), so we might want to keep the xxx()/xxx(boolean b) form in some places. I would deprecate the usage of XXX(boolean b) and useXXX(boolean b) and remove in 6. Thoughts? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Some flags are incompatible with implicit transactions
On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote: Why would you avoid FORCE_WRITE_LOCK ? Does the following make sense? tx.begin() cache.withFlags(FORCE_WRITE_LOCK).get(…) tx.commit() It doesn't in my view. You force a write lock to then to something within a transaction with the knowledge that the key is locked. Will I still be able to use an explicit cache.lock() operation? Acquiring a pessimistic lock might be an important functionality in some use cases. That's another interesting one, what's the point of doing: tx.begin() cache.lock() tx.commit() I don't see lock() being compatible with implicit tx. About FAIL_SILENT.. I'm not sure about the use case, but I would expect it to just avoid logging errors and to swallow eventual exceptions ? Javadoc: * pSwallows any exceptions, logging them instead at a low log level. Will prevent a failing operation from * affecting any ongoing JTA transactions as well./p I see not affecting the on going JTA transaction as the bigger motivator for using it rather than just avoiding showing the errors. Do you have any particular use case where the following makes sense? tx.begin(); cache.withFlags(FAIL_SILENT).put(k, v); tx.commit(); Sanne On 13 December 2011 12:10, Galder Zamarreño gal...@jboss.org wrote: Hi all, Re: https://issues.jboss.org/browse/ISPN-1556 Re: https://github.com/infinispan/infinispan/pull/719/files#r288994 The fix I suggest works well with explicit transactions, but if we leave this as is, implicit txs might leak transactions. The reason is because if we allow a put with FAIL_SILENT which fails with an implicit tx, then the tx won't be committed nor removed from tx table. But, does FAIL_SILENT make sense with implicit tx? Well, it doesn't. The point of FAIL_SILENT is to avoid a failure rollbacking a tx and being noisy. So, it implies that there's a bigger, external, transaction within which this operation is called. And it's not just FAIL_SILENT, there're other flags do not make sense with implicit transactions, such as FORCE_WRITE_LOCK: /** * Forces a write lock, even if the invocation is a read operation. Useful when reading an entry to later update it * within the same transaction, and is analogous in behavior and use case to a ttselect ... for update ... /tt * SQL statement. */ So, I think my fix is right here, but what we really need is it's a way to stop people from using certain flags with implicit transactions. Here's my (quickly thought) list: FORCE_WRITE_LOCK FAIL_SILENTLY PUT_FOR_EXTERNAL_READ Any others? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Some flags are incompatible with implicit transactions
I use the pattern: tx.begin(); cache1.lock(); ... tx.commit(); There are other caches involved in the transaction, but cache1 doesn't actually put any data. It's just there so I don't have to acquire 8-13 explicit locks on the other caches. Improved throughput in my application. I also use this pattern: tx.begin(); boolean result = cache.withFlags(FAIL_SILENT).lock(k); // Something interesting.. tx.commit(); ...Same reason. I have a pool of keys and if one fails, I go to the next one. Again, keeps me from needing to acquire a bunch of explicit locks. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Galder Zamarreño Sent: Tuesday, December 13, 2011 8:49 AM To: infinispan -Dev List Subject: Re: [infinispan-dev] Some flags are incompatible with implicit transactions On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote: Why would you avoid FORCE_WRITE_LOCK ? Does the following make sense? tx.begin() cache.withFlags(FORCE_WRITE_LOCK).get( ) tx.commit() It doesn't in my view. You force a write lock to then to something within a transaction with the knowledge that the key is locked. Will I still be able to use an explicit cache.lock() operation? Acquiring a pessimistic lock might be an important functionality in some use cases. That's another interesting one, what's the point of doing: tx.begin() cache.lock() tx.commit() I don't see lock() being compatible with implicit tx. About FAIL_SILENT.. I'm not sure about the use case, but I would expect it to just avoid logging errors and to swallow eventual exceptions ? Javadoc: * pSwallows any exceptions, logging them instead at a low log level. Will prevent a failing operation from * affecting any ongoing JTA transactions as well./p I see not affecting the on going JTA transaction as the bigger motivator for using it rather than just avoiding showing the errors. Do you have any particular use case where the following makes sense? tx.begin(); cache.withFlags(FAIL_SILENT).put(k, v); tx.commit(); Sanne On 13 December 2011 12:10, Galder Zamarreño gal...@jboss.org wrote: Hi all, Re: https://issues.jboss.org/browse/ISPN-1556 Re: https://github.com/infinispan/infinispan/pull/719/files#r288994 The fix I suggest works well with explicit transactions, but if we leave this as is, implicit txs might leak transactions. The reason is because if we allow a put with FAIL_SILENT which fails with an implicit tx, then the tx won't be committed nor removed from tx table. But, does FAIL_SILENT make sense with implicit tx? Well, it doesn't. The point of FAIL_SILENT is to avoid a failure rollbacking a tx and being noisy. So, it implies that there's a bigger, external, transaction within which this operation is called. And it's not just FAIL_SILENT, there're other flags do not make sense with implicit transactions, such as FORCE_WRITE_LOCK: /** * Forces a write lock, even if the invocation is a read operation. Useful when reading an entry to later update it * within the same transaction, and is analogous in behavior and use case to a ttselect ... for update ... /tt * SQL statement. */ So, I think my fix is right here, but what we really need is it's a way to stop people from using certain flags with implicit transactions. Here's my (quickly thought) list: FORCE_WRITE_LOCK FAIL_SILENTLY PUT_FOR_EXTERNAL_READ Any others? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Some flags are incompatible with implicit transactions
Hi, I guess I will troll a little here but it seems to me that the implicit transactions are the issue. What Galder suggested does makes sense( that you would want a failure to put in the cache in some circumstances to have no incidence) but some times if too many things are telling something does not make sense and cannot be done right... maybe it just should not be (e.g. implicit transactions). I know you feel strongly about the implicit transactions. Food for thought, I patched my version not to have them and I can tell you it works great! Good luck, Regards, Slorg1 On Tue, Dec 13, 2011 at 09:32, Erik Salter an1...@hotmail.com wrote: Offhand, the only other one I use is SKIP_REMOTE_LOOKUP to avoid serializing/deserializing return values I don't care about. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Sanne Grinovero Sent: Tuesday, December 13, 2011 9:24 AM To: infinispan -Dev List Subject: Re: [infinispan-dev] Some flags are incompatible with implicit transactions Right, it's also very useful to acquire locks on aggregates or groups by locking a representative known key for the group instead of on each element; very useful to guarantee consistency across disjoint elements in the grid. Erik, do you also SKIP_LOCKS or do other optimisations on the other operations? Sanne On 13 December 2011 14:12, Erik Salter an1...@hotmail.com wrote: I use the pattern: tx.begin(); cache1.lock(); ... tx.commit(); There are other caches involved in the transaction, but cache1 doesn't actually put any data. It's just there so I don't have to acquire 8-13 explicit locks on the other caches. Improved throughput in my application. I also use this pattern: tx.begin(); boolean result = cache.withFlags(FAIL_SILENT).lock(k); // Something interesting.. tx.commit(); ...Same reason. I have a pool of keys and if one fails, I go to the next one. Again, keeps me from needing to acquire a bunch of explicit locks. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Galder Zamarreño Sent: Tuesday, December 13, 2011 8:49 AM To: infinispan -Dev List Subject: Re: [infinispan-dev] Some flags are incompatible with implicit transactions On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote: Why would you avoid FORCE_WRITE_LOCK ? Does the following make sense? tx.begin() cache.withFlags(FORCE_WRITE_LOCK).get(…) tx.commit() It doesn't in my view. You force a write lock to then to something within a transaction with the knowledge that the key is locked. Will I still be able to use an explicit cache.lock() operation? Acquiring a pessimistic lock might be an important functionality in some use cases. That's another interesting one, what's the point of doing: tx.begin() cache.lock() tx.commit() I don't see lock() being compatible with implicit tx. About FAIL_SILENT.. I'm not sure about the use case, but I would expect it to just avoid logging errors and to swallow eventual exceptions ? Javadoc: * pSwallows any exceptions, logging them instead at a low log level. Will prevent a failing operation from * affecting any ongoing JTA transactions as well./p I see not affecting the on going JTA transaction as the bigger motivator for using it rather than just avoiding showing the errors. Do you have any particular use case where the following makes sense? tx.begin(); cache.withFlags(FAIL_SILENT).put(k, v); tx.commit(); Sanne On 13 December 2011 12:10, Galder Zamarreño gal...@jboss.org wrote: Hi all, Re: https://issues.jboss.org/browse/ISPN-1556 Re: https://github.com/infinispan/infinispan/pull/719/files#r288994 The fix I suggest works well with explicit transactions, but if we leave this as is, implicit txs might leak transactions. The reason is because if we allow a put with FAIL_SILENT which fails with an implicit tx, then the tx won't be committed nor removed from tx table. But, does FAIL_SILENT make sense with implicit tx? Well, it doesn't. The point of FAIL_SILENT is to avoid a failure rollbacking a tx and being noisy. So, it implies that there's a bigger, external, transaction within which this operation is called. And it's not just FAIL_SILENT, there're other flags do not make sense with implicit transactions, such as FORCE_WRITE_LOCK: /** * Forces a write lock, even if the invocation is a read operation. Useful when reading an entry to later update it * within the same transaction, and is analogous in behavior and use case to a ttselect ... for update ... /tt * SQL statement. */ So, I think my fix is right here, but what we really need is it's a way to stop people from using certain flags with implicit transactions. Here's my (quickly thought) list: FORCE_WRITE_LOCK FAIL_SILENTLY PUT_FOR_EXTERNAL_READ Any
Re: [infinispan-dev] Some flags are incompatible with implicit transactions
On Dec 13, 2011, at 3:00 PM, Sanne Grinovero wrote: On 13 December 2011 13:48, Galder Zamarreño gal...@redhat.com wrote: On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote: Why would you avoid FORCE_WRITE_LOCK ? Does the following make sense? tx.begin() cache.withFlags(FORCE_WRITE_LOCK).get(…) tx.commit() Yeah it's pointless to use locks if you have a single operation, but I might want to do more operations in a single transaction.. More than one cache operations in a single tx requires external or explicit tx management. Remember that here I'm refering to implicit transactions where each cache operation is surrounded by a tx: tx.begin(); cache.put your fav op here tx.commit; / tx.rollbacl(); actually what's the point of using a transaction if I have only one operation? That's what implicit transactions or autoCommit=true (if no external tx is on) gives you… ;) tx.begin() int counter = (Integer) cache.withFlags(FORCE_WRITE_LOCK).get(…) counter++; cache.put(k, counter); tx.commit() That's explicit tx management, outside the scope of this email. It doesn't in my view. You force a write lock to then to something within a transaction with the knowledge that the key is locked. Will I still be able to use an explicit cache.lock() operation? Acquiring a pessimistic lock might be an important functionality in some use cases. That's another interesting one, what's the point of doing: tx.begin() cache.lock() tx.commit() I don't see lock() being compatible with implicit tx. Same as above.. About FAIL_SILENT.. I'm not sure about the use case, but I would expect it to just avoid logging errors and to swallow eventual exceptions ? Javadoc: * pSwallows any exceptions, logging them instead at a low log level. Will prevent a failing operation from * affecting any ongoing JTA transactions as well./p I see not affecting the on going JTA transaction as the bigger motivator for using it rather than just avoiding showing the errors. Do you have any particular use case where the following makes sense? tx.begin(); cache.withFlags(FAIL_SILENT).put(k, v); tx.commit(); Don't ask me, but whoever invented the flag .. ;) If there are good use cases out of transaction, it might make sense in transaction as well. The primary use case for FAIL_SILENT is putForExternalRead() in my view and that happens, for the moment at least, within a transaction. Even if we end up requiring a PFER to run outside of a transation, we won't add implicit transactions or autoCommit cos that'd be useless. Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Some flags are incompatible with implicit transactions
On Dec 13, 2011, at 3:12 PM, Erik Salter wrote: I use the pattern: tx.begin(); cache1.lock(); ... tx.commit(); Right, but that pattern is not implicit tx where each cache operation is surrounded internally by a transaction. You are doing explicit or external tx management which is not what this email is asking. There are other caches involved in the transaction, but cache1 doesn't actually put any data. It's just there so I don't have to acquire 8-13 explicit locks on the other caches. Improved throughput in my application. I also use this pattern: tx.begin(); boolean result = cache.withFlags(FAIL_SILENT).lock(k); // Something interesting.. tx.commit(); ...Same reason. I have a pool of keys and if one fails, I go to the next one. Again, keeps me from needing to acquire a bunch of explicit locks. Again, same story. You are doing explicit tx management. Not in the scope of this email. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Galder Zamarreño Sent: Tuesday, December 13, 2011 8:49 AM To: infinispan -Dev List Subject: Re: [infinispan-dev] Some flags are incompatible with implicit transactions On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote: Why would you avoid FORCE_WRITE_LOCK ? Does the following make sense? tx.begin() cache.withFlags(FORCE_WRITE_LOCK).get(…) tx.commit() It doesn't in my view. You force a write lock to then to something within a transaction with the knowledge that the key is locked. Will I still be able to use an explicit cache.lock() operation? Acquiring a pessimistic lock might be an important functionality in some use cases. That's another interesting one, what's the point of doing: tx.begin() cache.lock() tx.commit() I don't see lock() being compatible with implicit tx. About FAIL_SILENT.. I'm not sure about the use case, but I would expect it to just avoid logging errors and to swallow eventual exceptions ? Javadoc: * pSwallows any exceptions, logging them instead at a low log level. Will prevent a failing operation from * affecting any ongoing JTA transactions as well./p I see not affecting the on going JTA transaction as the bigger motivator for using it rather than just avoiding showing the errors. Do you have any particular use case where the following makes sense? tx.begin(); cache.withFlags(FAIL_SILENT).put(k, v); tx.commit(); Sanne On 13 December 2011 12:10, Galder Zamarreño gal...@jboss.org wrote: Hi all, Re: https://issues.jboss.org/browse/ISPN-1556 Re: https://github.com/infinispan/infinispan/pull/719/files#r288994 The fix I suggest works well with explicit transactions, but if we leave this as is, implicit txs might leak transactions. The reason is because if we allow a put with FAIL_SILENT which fails with an implicit tx, then the tx won't be committed nor removed from tx table. But, does FAIL_SILENT make sense with implicit tx? Well, it doesn't. The point of FAIL_SILENT is to avoid a failure rollbacking a tx and being noisy. So, it implies that there's a bigger, external, transaction within which this operation is called. And it's not just FAIL_SILENT, there're other flags do not make sense with implicit transactions, such as FORCE_WRITE_LOCK: /** * Forces a write lock, even if the invocation is a read operation. Useful when reading an entry to later update it * within the same transaction, and is analogous in behavior and use case to a ttselect ... for update ... /tt * SQL statement. */ So, I think my fix is right here, but what we really need is it's a way to stop people from using certain flags with implicit transactions. Here's my (quickly thought) list: FORCE_WRITE_LOCK FAIL_SILENTLY PUT_FOR_EXTERNAL_READ Any others? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Some flags are incompatible with implicit transactions
On Dec 13, 2011, at 4:04 PM, Slorg1 wrote: Hi, I guess I will troll a little here but it seems to me that the implicit transactions are the issue. What Galder suggested does makes sense( that you would want a failure to put in the cache in some circumstances to have no incidence) but some times if too many things are telling something does not make sense and cannot be done right... maybe it just should not be (e.g. implicit transactions). I know you feel strongly about the implicit transactions. I don't feel strongly about them at all. If someone does it, maybe that's Mircea. Tbh, the more I think about it, the more I dislike implicit transactions... Food for thought, I patched my version not to have them and I can tell you it works great! Glad to know it's working fine for you :). Plenty going on at the moment. I'll be shortly getting around to reviewing your work… it's not forgotten! Good luck, Regards, Slorg1 On Tue, Dec 13, 2011 at 09:32, Erik Salter an1...@hotmail.com wrote: Offhand, the only other one I use is SKIP_REMOTE_LOOKUP to avoid serializing/deserializing return values I don't care about. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Sanne Grinovero Sent: Tuesday, December 13, 2011 9:24 AM To: infinispan -Dev List Subject: Re: [infinispan-dev] Some flags are incompatible with implicit transactions Right, it's also very useful to acquire locks on aggregates or groups by locking a representative known key for the group instead of on each element; very useful to guarantee consistency across disjoint elements in the grid. Erik, do you also SKIP_LOCKS or do other optimisations on the other operations? Sanne On 13 December 2011 14:12, Erik Salter an1...@hotmail.com wrote: I use the pattern: tx.begin(); cache1.lock(); ... tx.commit(); There are other caches involved in the transaction, but cache1 doesn't actually put any data. It's just there so I don't have to acquire 8-13 explicit locks on the other caches. Improved throughput in my application. I also use this pattern: tx.begin(); boolean result = cache.withFlags(FAIL_SILENT).lock(k); // Something interesting.. tx.commit(); ...Same reason. I have a pool of keys and if one fails, I go to the next one. Again, keeps me from needing to acquire a bunch of explicit locks. Erik -Original Message- From: infinispan-dev-boun...@lists.jboss.org [mailto:infinispan-dev-boun...@lists.jboss.org] On Behalf Of Galder Zamarreño Sent: Tuesday, December 13, 2011 8:49 AM To: infinispan -Dev List Subject: Re: [infinispan-dev] Some flags are incompatible with implicit transactions On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote: Why would you avoid FORCE_WRITE_LOCK ? Does the following make sense? tx.begin() cache.withFlags(FORCE_WRITE_LOCK).get(…) tx.commit() It doesn't in my view. You force a write lock to then to something within a transaction with the knowledge that the key is locked. Will I still be able to use an explicit cache.lock() operation? Acquiring a pessimistic lock might be an important functionality in some use cases. That's another interesting one, what's the point of doing: tx.begin() cache.lock() tx.commit() I don't see lock() being compatible with implicit tx. About FAIL_SILENT.. I'm not sure about the use case, but I would expect it to just avoid logging errors and to swallow eventual exceptions ? Javadoc: * pSwallows any exceptions, logging them instead at a low log level. Will prevent a failing operation from * affecting any ongoing JTA transactions as well./p I see not affecting the on going JTA transaction as the bigger motivator for using it rather than just avoiding showing the errors. Do you have any particular use case where the following makes sense? tx.begin(); cache.withFlags(FAIL_SILENT).put(k, v); tx.commit(); Sanne On 13 December 2011 12:10, Galder Zamarreño gal...@jboss.org wrote: Hi all, Re: https://issues.jboss.org/browse/ISPN-1556 Re: https://github.com/infinispan/infinispan/pull/719/files#r288994 The fix I suggest works well with explicit transactions, but if we leave this as is, implicit txs might leak transactions. The reason is because if we allow a put with FAIL_SILENT which fails with an implicit tx, then the tx won't be committed nor removed from tx table. But, does FAIL_SILENT make sense with implicit tx? Well, it doesn't. The point of FAIL_SILENT is to avoid a failure rollbacking a tx and being noisy. So, it implies that there's a bigger, external, transaction within which this operation is called. And it's not just FAIL_SILENT, there're other flags do not make sense with implicit transactions, such as FORCE_WRITE_LOCK: /** * Forces a write lock, even if the invocation is a read operation. Useful when
Re: [infinispan-dev] Some flags are incompatible with implicit transactions
Hi, On Tue, Dec 13, 2011 at 12:08, Galder Zamarreño gal...@redhat.com wrote: On Dec 13, 2011, at 4:04 PM, Slorg1 wrote: Hi, I guess I will troll a little here but it seems to me that the implicit transactions are the issue. What Galder suggested does makes sense( that you would want a failure to put in the cache in some circumstances to have no incidence) but some times if too many things are telling something does not make sense and cannot be done right... maybe it just should not be (e.g. implicit transactions). I know you feel strongly about the implicit transactions. I don't feel strongly about them at all. If someone does it, maybe that's Mircea. I did not mean you personally, I only referred to your name for the 'fail silently' feature. Sorry if it sounded like I was singling you out. I meant it as a general 'you', which only includes those who feel strongly about it. Tbh, the more I think about it, the more I dislike implicit transactions... I think they are really counter intuitive and very expensive, and arguably wrong in a pure transactional context like mine. I said 'arguably' because I do not want to restart the discussion about it, I just wanted to say people on this thread have different views about them, and leave it to that. Food for thought, I patched my version not to have them and I can tell you it works great! Glad to know it's working fine for you :). Plenty going on at the moment. I'll be shortly getting around to reviewing your work… it's not forgotten! I know, I am patient. Also, I have a few updates to give whenever I am done with my work here, so if you get to it before I send them, let me know. Regards, Slorg1 -- Please consider the environment - do you really need to print this email ? ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] RemoteCacheManager constructors
Hi, OMG, I've just counted 23 constructors in RemoteCacheManager! Do we really need them all? http://docs.jboss.org/infinispan/5.1/apidocs/org/infinispan/client/hotrod/RemoteCacheManager.html Something to cleanup in 6.0… Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] RemoteCacheManager constructors
I believe a fair few will be removed, yes. On 13 Dec 2011, at 17:17, Galder Zamarreño wrote: Hi, OMG, I've just counted 23 constructors in RemoteCacheManager! Do we really need them all? http://docs.jboss.org/infinispan/5.1/apidocs/org/infinispan/client/hotrod/RemoteCacheManager.html Something to cleanup in 6.0… Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
