Niclas Hedhman wrote:
> On Monday 14 April 2008 17:23, Rickard Öberg wrote:
>> Now I'm not too sure that's a good idea. The reason is that there are so
>> many ways to invoke side-effects asynchronously (separate thread, put in
>> JMS queue, send to JavaSpace, etc.), and they all have different
>> semantics, that I don't think it's going to be so easy as to just mark a
>> side-effect as @Asynchronous and that's it.
>
> I think I disagree... ;o)
>
> That it IS asynchronous is where the annotation comes in play. I mean, it
> either IS or is not asynchronous. One could perhaps say that we instead have
> a @Invocation taking an enum{ synchronous, asyncronous } as value, but
> practically the same thing.
>
> And IF it is asynchronous it is passed to some form of Asynchronizer, which
> figures out "how" the asynchronization is supposed to happen. I think the
> most straight forward way to do this would be to introduce such interface,
> which is registered as service in modules in good old fashion.
But that's no good since it forces all side-effects to be handled the
same way. If I have three side-effects on the same method I may want
them all to be handled differently, hence forcing the implementor to
deal with it will work, and the framework is less responsible for
ensuring that objects are valid when the side-effect actually executes
(VERY important). For example, if a side-effect gets a reference to an
Entity that Entity will most likely not be valid when the side-effect
actually executes, since the UoW it belongs to will most likely have
completed at that point.
> Pushing it to side-effect implementor seems unnecessary, and possibly not
> known either. I must say I wasn't able to follow your example...
Hm... ok what was it that was unclear? Can you be more specific?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
