Re: Embedded JavaSpaces

Jeff Ramsdale wrote:

[snip]

>
>
>>You might need to implement your own local transaction
>>manager to allow you to perform atomic operations but that's about
>
> it.
>
> I saw something about that in Blitz and didn't think through it. That
> makes sense, though.
>

Yep - it's not always necessary so you can often get away with a null
implementation that just tells the local JavaSpace that all is well.

>
>>>implementations--are there any others? I imagined it
>>
>>wouldn't be hard
>>
>>What criteria did you have in mind?
>
>
> Basically I was hoping for transparent switchability between a local
> and foreign JavaSpace based on a user configuration at runtime. That
> is, a properties file could indicate whether the user wanted to run in
> a local distributed mode. The embedded JavaSpace would always be used
> but additionally the remote JavaSpace could be used if the appropriate
> property were set.
>

Seems like something that could be abstracted via some sort of lookup
interface - interesting......

>
>>>to write one though I'm not sure my skills are up to the task. Any
>
>
>>>comments? Links?
>>>
>>
>>Depends exactly what you want - how many of the features of a
>>JavaSpace do you really need?
>>
>>IMHO (as an implementer), I'd say it was damned hard if you
>>need all the usual functionality, to write an implementation
>>yourself.  There are a surprising number of places where you
>>can get deadlocks, race conditions, state stability problems
>>and issues with blocking takes or reads (just when have you
>>considered all possible current matches?).
>
>
> I clearly wasn't thinking it through all the way--I haven't yet delved
> into transactions, so they didn't enter my thinking (I'll get there!).

Don't!  They're ugly :)

> We've written a wrapper for JavaSpace that deals with some of the
> threading issues one runs into with normal JavaSpace use so I can
> certainly understand the possibility for problems. (Incidentally, is
> there a semi-standard way of interacting with a JavaSpace to deal with
> the threading issues and notifies, etc., or does everyone write their
> own helper utility?)
>

Oh, uh, what threading issues are you talking about here?  Too many
possibilities to answer all in one go - are you referring to things like
not blocking a thread delivering a RemoteEvent and such like?


[snip]


>>Can't really contribute any other ideas but ask me more
>>questions and I'll try and satisfy your curious nature :)
>
>
> Don't know what I would add to the above. I imagined that it would be
> a somewhat common pattern to have applications doing work that would
> distribute some things and not others (perhaps based on
> configuration), suggesting the pairing of a local JavaSpace with a
> remote one. Guess not?
>

Nope - I think it's an interesting pattern - I've seen it used in
different fashions from the way you want to use it but it is being done.
  I think the thing I'd most like to figure out is what
abstraction/config etc fits best with this.

Dan.

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

JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/