Changes between Initial Version and Version 1 of Ticket #1869


Ignore:
Timestamp:
2012-11-20T01:12:36Z (13 years ago)
Author:
davidsarah
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #1869

    • Property Status changed from new to assigned

  • Ticket #1869 – Description

    initial v1  
    11The following issue needs to be fixed before the pluggable backends code is merged to trunk (#1819). Before pluggable backends, operations that access share storage were synchronous, and so two or more such operations could not run concurrently. This is important because clients make the assumption of serializability for accesses to a mutable share on a given server (if they are the only such client, which is implied by the Prime Coordination Directive).
    22
    3 Now that backend operations are asynchronous, they can run concurrently. That needs to be fixed. Note that operations on different sharesets do ''not'' need to be serializable with respect to each other (that would impose unnecessary delays).
     3Now that backend operations are asynchronous, they can run concurrently. That needs to be fixed. Note that operations on different sharesets do ''not'' need to be serializable with respect to each other. (That would impose unnecessary delays.)
    44
    5 The simplest way to implement this is probably to have a weak cache mapping storage indices to ShareSet objects, so that there can only be one ShareSet object per actual shareset, and then use a deferred queue in the ShareSet object to serialize operations. I'm not sure exactly where the cache should go yet.
     5The simplest way to implement this is probably to have a weak cache mapping storage indices to !ShareSet objects, so that there can only be one !ShareSet object per actual shareset, and then use a deferred queue in the !ShareSet object to serialize operations. I'm not sure exactly where the cache should go yet.