Re: take()-s of two associated but distinct entries

> Suppose, there are three processes (could be threads too), interacting
> through a Space. Two of them (A and B) produce Entries,
> and the other (C) consumes the entries. Thorugh the Entries are
> produced by two disconnected producers, there is a close assoication
> betwevn them. Hence, the C need to take() the Entries together
> before using them.

Fair enough, so you're needing to aggregate Entry from A [eA] and
Entry from B [eB] before you process them.

> Producers may or may not produce entries (and write() into the space),
> simultaneously. In other words, there could be a discernible time-gap
> between two such write()-s. The Consumer has registered itself
> for notification, for both type of entries. Obviously, there will be a
> time-gap between two notifications that C gets from the Space.

Okay, so you need to wait until both eA and eB have been written
before C can proceed.

> So, A produces an Entry named, AE1 and write()s into the Space. C gets
> the notification. Similarly, when B produces an Entry named, BE1 into
> the Space, C again gets the notification. Now, C has to take AE1
> and BE1.

Okay, so you need to wait until both eA (in this case AE1) and eB (in
this case BE1) have been written before C can proceed.


> What should C do?
>
> a) Should C take() them under two different transactions?
> b) Can C take() them under the same transactions? Will the same Txn
> object work across two separate take()-s?

C could do either, muliple takes, and indeed writes, can be grouped
into a single transaction. However a bigger concern is the time lag
between these two, an whether you're dependent upon eA being written
before eB. If general a transaction (particularly distributed ones)
should lock resources for the shortest amount of time possible. So you
should really take under two transactions, but if you have any probelm
in processing you should write both entries back to the space in a
single transaction.

> In a slightly different scenario, let us assume that there are two
> instances of C (C1 and C2) running. A writes entries AE1 and AE2.
> Similarly, B writes entries BE1 and BE2 (don't forget the time-gap).
>
> Now, take() by either C1 or C2 has to happen in associated pairs;
> in other words, whosoever takes AE1, has to take BE1 (ditto for
> AE2 and BE2).
>
> What is the most common (and efficient) pattern to be followed in such a case?

In this multi-consumer aggregator model, you need to:
a) Impose a sequential order, or an internal match
c) Use a correlation Identifer to associate pairs in some way

i.e.
a) Always take eA in the loop, and if you obtain eA then and only then take eB
b) You must have something that is common between eA and eB. This
doesn't have to be completely unique across the whole lifetime of your
space, but does need to be unique within a certain timeframe so that
you don't take any old eB or multiple eB.

if you don't want sequential order, you need to maintain a small cache
of notifications for all entries that you've been notified of, then
for every subsequent notification, you should try to correlate so that
you can get an eA<->eB match, whereupon you would attempt to take both
entries simultaneously, and then remove from the cache. If you can't
find those entries then you can assume that another Consumer has
matched, taken and processed them.
i.e.

eA is written - C1 and C2 are informed and log the data but there is no eB
....other eA entries may be written
eB is written that correlates with eA - C1 and C2 are informed, see
the matching eA entry in their logs.
C1 creates a transaction, takes both eA and eB, processes them
At the same time, C2 tries to take eA and eB, see sthat they are not
there, and removes them from it's log*

* Note that this doesn;t deal with transaction aborts in actually
processing the pair, but it shoudl work for getting a correlated pair
out under a single transaction

Hope this helps

--Calum

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html