I forgot to mention: a JavaSpaces05.writeIfAbsent method would be nice as well ...
Sent from my iPad www.objectscape.org Am 23.06.2011 um 10:25 schrieb Dan Creswell <[email protected]>: > Hi Oliver, > > There have been a number of experiments in this direction previously, > some of them listed elsewhere. Blitz JavaSpaces, GigaSpaces and indeed > Coherence (completely unrelated but relevant) all have more or less > experimental mechanisms used in various scenarios which prove that > such a feature is useful. > > Specifically with Jini, the difficulty is how to manage the lifecycle > of such code: > > (1) Does one install it statically at startup of the JavaSpaces > service or go more dynamic? > (2) If one goes with the dynamic option, how does one deal with > security (it's quite simple for a single-user, more complicated with > multiple users)? Does one even need security? > (3) How does one manage the increased memory usage and CPU of such a > solution? How might that be made to scale? > > If we want to take this forward then, I would suggest we need to > define an over-arching set of needs/policy then we can look at all the > stuff that's been done historically and > cherry-pick/mix-and-match/innovate our way to a solution. I would > imagine we ought to be aiming to come up with a standard interface > that perhaps extends JavaSpace05. > > Cheers, > > Dan. > > On 18 June 2011 10:39, Oliver Plohmann <[email protected]> wrote: >> Hello, >> >> the idea of Linda tuple spaces is to have a passive central space where >> clients can add or remove data. The client cannot invoke any server-side >> execution. This programming model is very well suited for a wide range of >> applications. But I'm asking myself whether it would make sense to allow for >> some server-side execution for certain exceptional cases where this makes >> sense. I guess this is some kind of perennial discussion ... >> >> Let's give an example. Lately, I was prototyping a a little stm framework. >> After a while I asked myself how to implement the commit of a transaction. >> Well, you change some atomic variable for all affected data in the >> transaction and then the new values become visible at once. Then I asked >> myself how you would implement that when developing a distributed stm system >> using JavaSpaces. The easiest way would be to send the change list of the >> transaction to the server and execute the code on the server-side to process >> the changes and change the atomic variable when doing the commit. But this >> cannot be done, because there is no way to spawn some server-side thread in >> JavaSpaces. Then, I have to do the commit on the client-side. This will >> necessarily result in a lot more traffic between the client and the central >> tuple space. >> >> Now someone might say, that GigaSpaces or whatever system supports >> optimistic locking and therefore to implement a distributed stm system with >> GigaSpaces or whatever would be no problem. The point is here that a >> distributed stm system is only an example of why server-side execution might >> be justified in certain circumstances. You can find other examples for >> things for which some JavaSpaces implementation has no direct support and >> you are confronted with the same question whether there should be an option >> to do some server-side execution in JavaSpaces. >> >> So my point is merely "philosophical". If I were the owner of JavaSpaces I >> would try to make sure that the clean and elegant programming model of Linda >> tuple spaces won't fall apart and let things remain the way they are. But >> the question whether some server-side execution makes sense still bothers >> me. What do you think? >> >> Regards, Oliver >> >> >> www.objectscape.org >> >>
