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
