Re: Outrigger. Jini2.1

This explains it fully.
I had seen the subtelity of the difference between  take() and
takeIfexists().
The line 
"or there are no matching entries in the space (locked or otherwise)."
That u used to explain the behaviour takeIfexists() made through .
 


Thus this explains that from a client perspective and I mean a piece of
code that uses the JavaSpace instance (client code ) any interaction
from the perspective of the JavaSpace is threadsafe. 



-----Original Message-----
From: John McClain [mailto:[email protected]] 
Sent: Friday, February 10, 2006 1:48 PM
To: [email protected]
Subject: Re: Outrigger. Jini2.1

Santoshi, Vishal wrote:
> Cool.
> Is the synchronization issues taken care of in the client code to the
> javaspace or is it an artifact of the space itself.

Not quite sure if I understand the distinction you are making, but the
JavaSpace service as a whole is expected to be thread safe. This should
be true if there a n clients with 1 thread each, or 1 client with m
threads, or n clients with m threads, etc.

> For example
>
> A handover of an entry to the space if done in a transaction should
> block any act of trying to retrieve it if we use takeIfexists() and to
> some extent take(the API seems to indicate that it may not allow dirty
> read) .This is  if we pass a transaction along .

Yes, though I am not sure you have the (subtle) difference between take
and takeIfExists right (it took me a few years to really "get it"...).
If they find an available match take and takeIfExists have the same
impact, they remove the entry from the space, optionally under a
transaction in which case the entry is provisionally removed pending
transaction commit. While the transaction is in the unresolved state no
other query will return the removed entry.

How they differ is how they behave if there are no available matching
entries. A take will wait until either a match becomes available (either
by a new entry being written or the resolution of a previously
conflicting transaction), or the timeout expires (in which case null is
returned).  A takeIfExists will wait until a match becomes available (as
above), the timeout expires (as above), or there are no matching entries
in the space (locked or otherwise). Put another way, take will block on
an empty space, takeIfExists will not. Put yet another way, takeIfExists
only blocks on conflicting transactions.

> Now if the transaction
> is null , theoreticaly a takeifExists can give a copy to two different
> threads .

No, this can't happen. If a take (or takeIfExists) returns an entry no
query started after that take returns will get that entry. If two or
more take/takeIfExists calls are going on in concurrently they will all
return distinct entries (or null if there are insufficient entries
available). Of course if there are 4 identical entries in the space and
4 concurrent takes they could each return one of the 4 entries.

> Is this therefore handled at the code level , or does
> javaspace itself does not allow that , or is the above hypothesis
wrong
> to begin with.

At lease part of the hypothesis is wrong, but also I don't understand
the distinction between "code level" and the "javaspace itself". Is
"code level' client code? Space proxy code? something else?

Hope this all helps, if not I can try again...

========================================================================
===
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

===========================================================================
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