Some additional lock-levels (apart from write, synchronous-write) can give
applications along more choices along correctness/latency trade-offs.
------------------------------------------------------------------------------------------------------------------------------------------------
Key: CDV-728
URL: https://jira.terracotta.org/jira//browse/CDV-728
Project: Community Development
Issue Type: New Feature
Affects Versions: 2.6-stable0
Reporter: Sreenivasan Iyer
Assignee: Issue Review Board
Lock--level Write => Terracotta Transaction written to Commit Buffer and based
on l1.transactionmanager properties, it gets flushed to L2 Asnchronously.
There is some exposure here in that
1. If this JVM (L1) dies, some uncommitted "Terracotta Transactions" in the
commit buffer aren't yet been flushed,
2. If any other component of the cluster fails, there is *no* exposure since
upon rejoining the cluster, this JVM will retransmit the transaction and manage
it as "in-flight" until the L2 Acks back.
So with regards to the exposure in (1), i.e. for applications with
requirements around greater levels of guarantees around Terracotta-transaction
commits, Terracotta supports Synchronous-Write Lock-Level, where upon the
calling thread blocks until the "Terracotta Transaction" is committed. However
adoption of this feature is stunted, given the performance costs associated
with it. Current understanding is that the Application Calling thread will
block until the L2 Acks, which it will do so only after:
1. The transaction gets applied on Primary L2 (which in turn may synch-relay it
to Secondary L2 in NAP and/or persist to disk).
2. ACKs are received from all other L1s to which the change was broadcast to.
So to trade-off the risk/reward (i.e. guarantees v/s
latency-issues-experienced-by-calling-application-thread), several DSO users
request that we support more finer-grained synchronous-write lock levels.
EXAMPLE - support synchronous-write-Lite where-in the flush from the L1
Commit-Buffer to the Primary L2 is synchronous (so data is in at least 2 places
instead of the usual N for the best possible guarantee), but the persistence to
disk and/or ACKS from other L1s happen asynchronously.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.terracotta.org/jira//secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
