[ 
http://jira.jboss.com/jira/browse/JBCACHE-69?page=comments#action_12314835 ]
     
Bela Ban commented on JBCACHE-69:
---------------------------------

[Gavin]
Guys, here is my proposal, this is what I want people
to use with Hibernate, but it is actually generic:

The following algorithm basically lets the database
define an ordering of update messages for a particular
cache item. (It is not an ordering of all messages.)

(1) During the txn, cache.put(key, value) simply adds
   the key/value pair to a transaction-local collection
   of scheduled puts. The change is not yet visible to
   other, concurrent txns and the node is not locked.

(3) During afterTransactionCompletion, the collection of
   puts is applied to the local cache, and replicated to
   all other instances in the cluster. (All puts can be
   replicated in a single message.)

(4) When a put is actually applied (either to the local
   or remote cache instance), try to cast the value to
   VersionedItem. If successful, call
   value.isLaterThan(currentValueInCache), and actually
   apply the put only if isLaterThan returns true.
  Consequences:

(1) If no node fails, the cache will remain consistent
   with the database, apart from a short time after an
   update, while replication occurs, when stale data
   can be read by other transactions. (Note that
   staleness is not a huge problem, because we have
   optimistic locking at db level, to prevent lost
   updates.)

(2) If we use guaranteed delivery and a node fails,
   the cache will contain stale data until the
   message is eventually delivered.
  (3) If we configure a timeout based cache eviction
   policy, and a node fails, the cache will contain
   stale data for at maximum, the length of the
   timeout.

(2) No cached item is ever locked, and no voting ever
   occurs. 

> Optimistic Locking
> ------------------
>
>          Key: JBCACHE-69
>          URL: http://jira.jboss.com/jira/browse/JBCACHE-69
>      Project: JBoss Cache
>         Type: Feature Request
>     Reporter: Bela Ban
>     Assignee: Bela Ban
>      Fix For: 1.5

>
> Original Estimate: 10 weeks
>         Remaining: 10 weeks
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to