[
https://issues.apache.org/jira/browse/RIVER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002556#comment-13002556
]
Cees de Groot commented on RIVER-393:
-------------------------------------
It's probably obvious, but a commercial resilient implementation is available
(GigaSpaces), and the ideas they implemented are pretty straightforward. It
might prove as "inspiration" :-)
> Distributed Java Space
> ----------------------
>
> Key: RIVER-393
> URL: https://issues.apache.org/jira/browse/RIVER-393
> Project: River
> Issue Type: New Feature
> Components: net_jini_space
> Environment: All
> Reporter: Tom Hobbs
> Assignee: Tom Hobbs
>
> Currently, if you put an entry in a JavaSpace, and that space fails, you've
> lost your entry. Hence the current functionality only provides a
> single-point-of-failure-space. How should a distributed space work? What
> are the trade offs that users are prepared to accept to get resilient spaces
> (RS)?
> Naively, I can think of two possible writing to spaces;
> - Block the write method call until the RS is happy the entry is persisted
> safely
> - Return immediately and supply a Future-like implementation which the
> client can check later (if they want to) that the entry was persisted safely.
> (Optimistic writing?)
> Additionally, an interesting question is should a RS force all client/space
> operations be part of explicit transactions?
> Reading and taking methods become more interesting, but seem (to me) to be
> implementation details once the above questions have been answered.
> This issue is a request for interested parties to record their thoughts on
> how an RS should be used and designed and what specific considerations and
> requirements they might have.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
