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
