Ok, thanks :-) On 07 Sep 2007, at 08:16, Steven Harris wrote:
> Nope, Concurrent is a free for all and should rarely be used. If it > is used it should > be used by people who know what they are doing :-) > > On Sep 6, 2007, at 11:12 PM, Geert Bevin wrote: > >> Ok, thanks! >> >> Curious now, so there is some kind of transaction isolation then? Is >> this basically the same as the traditional 'serializable' isolation >> that prevents any kind of dirty reads to the changes that haven't >> been applied yet? Are those changes also not applied to the local >> data structures or is this only cluster-related? >> >> On 07 Sep 2007, at 08:03, Steven Harris wrote: >> >>> The transaction is an atomic set of changes that either will be >>> applied to the cluster in whole >>> or not at all. >>> >>> On Sep 6, 2007, at 11:01 PM, Geert Bevin wrote: >>> >>>> Hmmm, do you mean here that they instate memory barriers to ensure >>>> that those instructions aren't reordered or missed in a cache on >>>> another node/thread? I thought Terracotta didn't do anything >>>> transaction-related (isolation, commit-rollback, ...)? >>>> >>>> On 07 Sep 2007, at 07:50, Steven Harris wrote: >>>> >>>>> concurrent locks provide transaction boundaries with no >>>>> locking. In >>>>> that sense they are miss-named because >>>>> they aren't actually locks >>>>> >>>>> On Sep 6, 2007, at 10:47 PM, Geert Bevin wrote: >>>>> >>>>>> In general, one thing I've been wondering about: what's the >>>>>> difference between using concurrent locks and using no locking at >>>>>> all? >>>>>> >>>>>> On 07 Sep 2007, at 02:58, Gary Keim wrote: >>>>>> >>>>>>> Currently only read and write autolocks can be auto- >>>>>>> synchronized. >>>>>>> Does it >>>>>>> not makes sense to allow concurrent and synchronous-write >>>>>>> autolocks >>>>>>> to also >>>>>>> be auto-synchronized? >>>>>>> >>>>>>> In addition to: >>>>>>> >>>>>>> ConfigLockLevel.AUTO_SYNCHRONIZED_READ >>>>>>> ConfigLockLevel.AUTO_SYNCHRONIZED_WRITE >>>>>>> >>>>>>> Shouldn't there also be: >>>>>>> >>>>>>> ConfigLockLevel.AUTO_SYNCHRONIZED_SYNCHRONOUS_WRITE >>>>>>> ConfigLockLevel.AUTO_SYNCHRONIZED_CONCURRENT >>>>>>> >>>>>>> Rational: the concept of automatically introducing a monitor is >>>>>>> orthogonal >>>>>>> to the type of lock on that monitor. >> >> -- >> Geert Bevin >> Terracotta - http://www.terracotta.org >> Uwyn "Use what you need" - http://uwyn.com >> RIFE Java application framework - http://rifers.org >> Music and words - http://gbevin.com >> >> _______________________________________________ >> tc-dev mailing list >> [email protected] >> http://lists.terracotta.org/mailman/listinfo/tc-dev > > _______________________________________________ > tc-dev mailing list > [email protected] > http://lists.terracotta.org/mailman/listinfo/tc-dev -- Geert Bevin Terracotta - http://www.terracotta.org Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ tc-dev mailing list [email protected] http://lists.terracotta.org/mailman/listinfo/tc-dev
