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
