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