[Haskell-cafe] Persistent Concurrent Data Structures

[David Barbour]

Several of the Haskell web server frameworks (Yesod, HAppS, etc.) come with
persistence support.

I believe you're taking the wrong approach here, with respect to `modified
concurrently` and the like. What does it mean for a Data.List to be
'modified concurrently'? If you need concurrency, first find a good
abstraction for a concurrent collection - one that already covers such
details as ordered or collaborative updates. The result might not look much
like Data.List.



On Tue, Nov 1, 2011 at 3:31 PM, dokondr <dokondr at gmail.com> wrote:

> Hi,
> Please comment on the idea and advise on steps to implement it.
> Real world applications need persistent data, that can be accessed and
> modified concurrently by several clients, in a way that preserves
> "happen-before" relationship.
> Idea: Design and implement Persistent Concurrent Data Types in Haskell.
> These data types should mirror existing Data.List , Data.Map and similar
> types but provide persistency and support consistent concurrent access and
> modification (or simply - "concurrency").
> Persistency and concurrency should be configurable through these type
> interfaces. Configuration should include:
> 1) Media to persist data, such as file, DBMS, external key-value store
> (for example Amazon SimpleDB, CouchDB, MongoDB, Redis, etc)
> 2) Caching policy - when (on what events) and how much data to read/write
> from/to persistent media. Media reads / writes can be done asynchronously
> in separate threads.
> 3) Concurrency configuration: optimistic or pessimistic data locking.
>
> One may ask why encapsulate persistency and concurrency in the data type
> instead of using "native" storage API, such as for example key-value /
> row-column API that  NoSQL databases provide?
> The answer is simple: APIs that your code use greatly influence the code
> itself. Using low-level storage  API directly in your code results in
> bloated obscure code, or you need to encapsulate this low-level API in
> clear and powerful abstractions. So why not to do this encapsulation once
> and for all for such powerful types as Data.Map, for example, and forget
> all Cassandra and SimpleDB low-level access method details?
> When the right time comes and you will need to move your application to
> the next new "shiny_super_cloud", you will just write the implementation of
> NData.Map backed by Data.Map in terms of low-level API of this super-cloud.
>
> (Side note: I really need such a NData.Map type. I was requested to move
> my code that heavily uses Data.Map and simple text file persistence into
> Amazon AWS cloud. Looking at SimpleDB API, I realized that I will have to
> rewrite 90% of code. This rewrite will greatly bloat my code and will make
> it very unreadable. In case I had NData.Map I would just switch
> implementation from 'file' to SimpleDB persistency inside my NData.Map
> type.)
>
> Implementation:
> To start playing with this idea, NData.Map persisted in a regular file
> will do, no concurrency yet. Next step -   NData.Map persisted in SimpleDB
> or Cassandra or Redis, with concurrent access supported.
>
> So it looks like  NData.Map should be a monad ...
> Any ideas on implementation and similar work?
>
> Thanks!
> Dmitri
> ---
> http://sites.google.com/site/dokondr/welcome
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111101/3f464b98/attachment.htm>