> -----Original Message----- > From: Simon Nash [mailto:[email protected]] > Sent: Thursday, December 09, 2010 8:41 PM > To: [email protected] > Subject: Re: Elementary question about Scopes > [snip
> For sharing intermediate computation results between multiple methods > of > the same instance object, I would find it very cumbersome to arrange > all my method signatures to make sure the necessary data is passed > around. Agreed, it can be cumbersome. On the other hand, I once had to make a service COMPOSITE which was previously stateless, because for performance reasons I needed to introduce a cache to hold results of expensive computations from earlier requests. Had I used instance variables in the stateless early version, this might have caused problems or confusion once the service became stateful. Of course, I could have solved my caching problem the old-fashioned way by keeping the service declaration as stateless, and using static variables for the cache. Now that would have been confusing as well, wouldn't it? Or would that seem appropriate to you? Perhaps it would be better not to have to declare the service itself as stateless or stateful, but rather have scope annotations on each individual instance variable. > Also, the approach you're suggesting has the issue of introducing a > redundant > COMPOSITE scoped instance which has no apparent useful purpose. This > object > has no mutable state, because all mutable state is stored in method > local > variables that are passed around as parameters. This seems strange, as > the > purpose of COMPOSITE scope in SCA is to provide mutable state that's > shared > between requests. Using it for this other purpose means that people > who > read the code and see the scope declared as COMPOSITE are likely to > find it > harder to understand whether the service has stateful or stateless > semantics. > > Simon > I understand how that might be confusing. However, such abuse of COMPOSITE scope came to me quite naturally in one case, where my real aim was to make sure that the @Init method was only executed once. The reason being not just computational expense, but rather that I wanted to establish preconditions for the use of the service (like creating certain entities in a backend etc.) These actions should not be repeated on each service method call, although the service itself had stateless semantics. What would you suggest to handle this? Is there a better place to do things like this than the @Init method? Or would it make sense to have a new annotation for this purpose, something like @OnLoad ? -- Sebastian
