Although the default pooled service model is limited, it is likely sufficient for most needs.
By writing your own service model, you can implemented an improved version of the pooled service and make use of a more full-featured solution such as commons pool. On Mon, 25 Oct 2004 23:01:54 +0700, Jean-Francois Poilpret <[EMAIL PROTECTED]> wrote: > > > > I much agree with James. > > > > Having a pooled service model that brings some enhancements to the current > one is one point. > > Having a service that provides asynchroneous execution of services (possibly > with a scheduler) is another point. > > > > For me a service model should not be limited to work only with services that > have only void methods (and also non throwing exceptions, by the way: this > reminds me of the "oneway" keyword in CORBA, as far as I remember at the end > nobody would use that keyword because it prevents any assurance of a method > -correct- execution). > > My original request was really in this sense: extending the current pooled > service model in a way to, primarily, avoid resource waste (after a period > of heavy load for instance). > > > > I don't know how the pooled model is currently implemented in HiveMind, I am > not sure that having it changed to use commons pool would be easy, nor > advisable (it seems one of Howard's goals is to keep dependencies to the > minimum). I will try to have a quick look at it when I have time (at least > to understand how service models are developed). > > > > One additional comment about the use of concurrent packages (for an > asynchroneous scheduler for instance): if it was to be a part of HiveMind > core, then this would introduce still another dependency (since HiveMind is > claimed to work on JDK1.3, and I see no reason why this should change until > some time: I do not think we can expect everybody to switch to JDK5 until > years, personally I did not try it yet!) > > > > Cheers > > > > ________________________________ > > > From: James Carman [mailto:[EMAIL PROTECTED] > Sent: Monday, October 25, 2004 9:42 PM > To: [email protected] > Subject: RE: Pooled Service Model enhancements > > > > Well, I don't really like it and I don't think it should be part of core > HiveMind, but you can feel free to implement it yourself. I don't like it > because you really have to be careful what you're doing when you start using > asynchronous calls like this seamlessly. Clients have no idea that the call > goes on asynchronously! I see the merits of what you're proposing, but I > think making it very explicit (using a service point and implementing > Runnable or providing some reflective mechanism) is a bit safer. It's one > thing to manage what specific INSTANCE of an implementation object is used > behind the scenes to carry out the logic of a method call (the job of a > service model), but it's a completely different thing to seamlessly switch > the method call to asynchronous behind the scenes. Not only that, but you > have to make sure your methods are ALL void methods in your service > interface. Also, what do you do with exceptions that are thrown during > execution of the service method? What about transactions? > > > > -----Original Message----- > From: Pablo Lalloni [mailto:[EMAIL PROTECTED] > Sent: Monday, October 25, 2004 10:12 AM > To: hivemind-dev > Subject: RE: Pooled Service Model enhancements > > > > El lun, 25-10-2004 a las 10:37, James Carman escribi�: > > What if the service interface's method returns something? How can it be > asynchronous? > > > Of course, asynchronous calls doesn't expect to return a value... that's > the whole point. > > > > I agree that the Executor interface could be used as a service itself, but > to use that idea as a service model doesn't work IMHO. My suggestion would > be to expose the Executor (or actually ExecutorService in JDK 5.0) interface > as a service in your registry (as you've already done it seems) and let > other services use it. A service model itself cannot be asynchronous, as it > is a mechanism for performing a method call (which is inherently > synchronous) on an object. Even when you call the Executor.execute() > method, it's a synchronous call. The method does what it's supposed to do > (adds the Runnable to a queue or something) and returns. > > > I partially agree with you, but I think that wrapping the asynch/pool/queue > behaviour in the service-model would make things a lot cleaner and > shorter... no need the extra SPs, no need to implement runnable, etc... Of > course the methods called with this model/s should not return any value but > void. > > > -- Pablo I. Lalloni Tel�fono +54 (11) 4347-3177 Proyecto PampaDirecci�n > Inform�tica TributariaAFIP -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
