Without considerably more detailed discussions (with minimal beer intake) I wouldn’t say one way or the other.

However, I believe there are some constraints on contents which are not present in bulk take and can be exploited so as to make bulk take reasonably performant in the common case.

From another angle, if one were following the JavaSpaces spec to the letter I believe it would rule out most optimizations that would make a cluster performant. So, if we’re building a cluster we are likely bending some rules anyways and I think there are some rules in bulk-take that can be bent more than those in contents.

Dan.

Dan correct me if i’m wrong but based on my understanding “bulk-take” can be even more challenging then the “content” method under clustered environment. Imagine the following scenario as an example:

If your running bulk-take in a partitioned/clustered environment you can end up in a scenario in which the “bulk-take” may return from one of the spaces while other take is still performed on other spaces causing entries from those spaces to be lost.
Based on that bulk-take can be made pretty useless in a clustered environment due to its blocking nature. You may be able to implement it in a way that will work properly however it would be extremely expensive in terms of performance which again makes it pretty useless under clustered scenario.

Nati S.

Re: the spec, absolutely - as with so many things, the River project needs to reach consensus on what to do with this issue. Will all this stuff be put in the JavaDoc or separated into specs or written up on a Wiki, who “owns” it etc. My own view is KISS and keep the specs separate plus revise to include JavaSpace05 but I can’t predict or promise anything.

No, I’m not casting blame - just trying to be of service and given all the queries I see about this stuff, it seemed right to “blogit”.

Re: guidance on usage well I’m looking for feedback. See, some people want a book, some people want a Wiki, some people want it in specs and so on - any views on what works best would be useful. I’d also like to draw attention to a conflicting dynamic that I face daily which is that I have the knowledge to answer those questions and others but I have to make a living and writing my knowledge down in a book is neither cost effective nor profitable, the same being true for other “modes of delivery”. The only option that appears to allow me to satisfy the twin goals of education and making a living is consulting right now. Thoughts on how to deal with that catch-22 situation would also be gratefully received. Maybe I need to do an electronic book and charge by the chapter or something for download????

On quality of the docs, yeah I think people know but someone has to step up and take control of that. IMHO, thus far there are plenty of people that want control or have an opinion but aren’t prepared to back that up with a commitment to the work involved i.e. They want their opinion to carry weight but want someone else to do the work for them - not gonna work I fear…….

Yes, but remember that the javaspaces documentation needs some work. e.g. the javaspaces 2.1 specification per se does not refer to javaspace05 interface.

I don’t think you were casting any “blame” in this message, but I will take the opportunity to re-emphasize to the jini community — the documentation is not that great. The biggest key to adoption of the new River effort will be *much* better documentation than has been available for the last half decade or so.

When I was looking at events I remember reading through the javaspaces notification stuff and the general jini notification stuff. At the time I think I passed right over javaspace05 for the reason above.

Beyond the spec though is, when and why would I choose to use either of the javaspace notification capabilities? I’m not sure I’ve seen any help on that. But I could be wrong since jini/javaspaces information is just so scattered — I have trouble keeping the right set of information nearby.

I don’t want to be laying this all on your doorstep (blogstep). Hopefully the long time participants understand just how bad it is. It is discouragingly bad.

I’ll tackle these in order:

“So I assume that it is it correct to say that JavaSpace05.registerForAvailabilityEvent() is similar to a subscription in JMS?”

Well yes, because get a copy of the relevant Entry in the delivered event but you have to remember that the Entry will still be in the space of course. Also, you can get “additional” events triggered by for example, open txn, take entry, abort txn which would signify the entry becoming available for other consumers.

“Also do you know why JavaSpace05 is an optional extension? ”

To be honest, I can’t recall whether there was a reason even though I was involved (as a JavaSpaces implementor myself of course) in the work. If you asked me now if making it optional made sense I’d say yes. This is because JavaSpace05 introduces an additional order of complexity to the implementation and it can be resource intensive in some circumstances which would preclude certain deployment options (the contents method for example can be unfriendly in a clustered implementation).

“Oh yeah and meant to say thanks Dan.”

You’re welcome!

So I assume that it is it correct to say that JavaSpace05.registerForAvailabilityEvent() is similar to a subscription in JMS?

Also do you know why JavaSpace05 is an optional extension?