Udi Dahan wrote:
> Actually, javaspaces provide fault tolerance via replication instead of
> durability, but, ok.
I don't think you've read the spec. There is no such requirement in the spec.
Different implementations can choose to provide what ever level of replication
or durability they choose.
See here, there is nothing about durability or replication implied:
public interface JavaSpace {
Lease write(Entry entry, Transaction txn, long lease)
throws TransactionException, RemoteException;
Entry read(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
Entry readIfExists(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
Entry take(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
Entry takeIfExists(Entry tmpl, Transaction txn, long timeout)
throws UnusableEntryException, TransactionException,
InterruptedException, RemoteException;
EventRegistration
notify(Entry tmpl, Transaction txn, RemoteEventListener listener,
long lease, MarshalledObject handback)
throws TransactionException, RemoteException;
Entry snapshot(Entry e) throws RemoteException;
}
> I’m quite familiar with using these kinds of technologies in scenarios
> similar to that which I outlined in my blog post and there are other
> issues that aren’t magically handled by the space, still requiring
> solutions like those I outlined.
I agree that a JavaSpace doesn't provide any particular solution to durability,
but it can provide an architecture that deals with durability better through
the
use of transactions.
One thing to note is that a JavaSpace is not a multi-cast conveyer like a
pub/sub system is typically. An Entry in a JavaSpace can be inspected multiple
times, but it can be taken only once. Thus a JavaSpace is truely targeted at
fanning out processing, not at distribution of data to multiple parties.
> For instance, when a publisher puts a message/event into the space, how
> long of a lease should it have? Too long and you may run out of memory
> in the space, too little and subscribers that were unavailable can miss
> it. That being said, these memory based solutions can be much more
> performant than disk based solutions.
The whole purpose of a space is to ignore subscribers that are unavailable.
The
whole purpose of the configurable lease it to allow each producer to control
the
lifecycle of its Entries instead of forcing separate "queues" or flows to have
to be used such that a client has to know everything to subscribe to. A
pub/sub
world is typically limited to fire-and-forget (here's my current state), keep
trying till you get it there (important data that is sequence or id
identifiable) and make sure you get it there only once (money exchanges).
Subscribers in a space sense, are either there, or not. If they are not there,
they don't provide processing power. This is why spaces scale so well at
distributed processing applications. You just add worker clients of the space
to get more processing "power" and if you over scale, you have some backup
horsepower.
In a pub/sub environment it's really a different game because of how those APIs
typically work and how transactions can be used. In a JavaSpace application I
can layer transactional exchanges and do things between two applications using
a
transaction to create a queue. Or, I can just put stuff in and let anyone
consume it. The JavaSpace provides flexibility and the power to manage lots of
things on a producer consumer decided QOS.
Gregg Wonderly
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
