The work I did on my griddle.dev.java.net project was to allow this kind of thing to happen.
With griddle, data and keys are separated and comparison is programmable. There is iterator and executor support on the server side, with executors just returning an iterator. It was just some exploratory work, but it dis function in the testing I did with it. It probably is not packed in a way for production use, yet. Gregg Wonderly Sent from my iPhone On Jun 18, 2011, at 4:39 AM, 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 >
