Hi Oliver, actually, I think you've picked up on something very interesting. It's something that I've been kicking around in my head for a while. I have more general ideas though.
One of the things I've used javaspaces for has been to contain discrete items if work that are then picked up by workers for execution, a standard pattern for sure. I think that there's mileage in modifying that pattern so the implementation of the workers is bundled into the entry of the space. That looks a little like a distributed Executor to me. Would you be interested in putting together a Jira issue to track this as a River enhancement? Cheers, Tom Grammar and spelling have been sacrificed on the altar of messaging via mobile device. On 19 Jun 2011 13:18, "Gregg Wonderly" <[email protected]> wrote: > 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 >>
