-
1. Re: Application Scoped components for singleton pattern?
luxspes Jan 14, 2009 9:38 PM (in response to toppac.toppac.gmail.com)
Allan Topp wrote on Jan 14, 2009 21:28:
My current client has elected not to use EJBs in their application at all. So right now they have most items that would be SLSB (services, daos, etc) listed as Session scoped components. I really don't see a need to create a new instance for every Session. Conversation scope again has problems since we don't always have a long running conversation and I don't want to instantiate a new instance each time. I am looking at using Application scope on the components to give them a singleton approach.
I do not think the Application scope is a good idea for this, remember that you are going to have multiple concurrent requests (applications servers are multi-threaded you know) that makes it a really bad idea (from a performance perspective) to share the same object all you users.
I realize this opens up some issues but as long as we can effectively keep them stateless I don't think we will have problems.
And why not use ScopeType.STATELESS ?
I guess I am looking for some input from the community on whether this approach is good or whether I am being over cautious about using Session scope. Would event scope make more sense? What is the general thinking?
I think you best option in this case is to use ScopeType.STATELESS for stateless stuff. ScopeType.SESSION would be a waste of memory if you are not really interested stateful behaviour (saving information between requests). -
2. Re: Application Scoped components for singleton pattern?
stephen Jan 14, 2009 10:58 PM (in response to toppac.toppac.gmail.com)
Francisco Peredo wrote on Jan 14, 2009 21:38:
Allan Topp wrote on Jan 14, 2009 21:28:
My current client has elected not to use EJBs in their application at all. So right now they have most items that would be SLSB (services, daos, etc) listed as Session scoped components. I really don't see a need to create a new instance for every Session. Conversation scope again has problems since we don't always have a long running conversation and I don't want to instantiate a new instance each time. I am looking at using Application scope on the components to give them a singleton approach.
I do not think the Application scope is a good idea for this, remember that you are going to have multiple concurrent requests (applications servers are multi-threaded you know) that makes it a really bad idea (from a performance perspective) to share the same object all you users.I have to disagree: Application scoped components are not synchronized by default (see Seam reference "4.1.10. Concurrency model"). So even if it is the same object, it will handle concurrent requests just fine. But of course you really have to
keep them stateless
to support multiple concurrent threads.
IMHO application scoped components are fine for this scenario. -
3. Re: Application Scoped components for singleton pattern?
toppac.toppac.gmail.com Jan 15, 2009 3:35 AM (in response to toppac.toppac.gmail.com)This was my thinking also. While I know Application scope is not ideal it seems the best fit for a stateless singleton approach. It lacks the poolable, transactions of EJBs but doesn't have the overhead of Session scope or Event scope. I'd much rather use Stateless EJBs but like I said the client prefers not to use them based on past experiences.
-
4. Re: Application Scoped components for singleton pattern?
toppac.toppac.gmail.com Feb 2, 2009 7:57 PM (in response to toppac.toppac.gmail.com)I am having second thoughts about this now. Since multiple developers are coding for this project enforcing a strict
stateless
design of their components will be very difficult. For components that need to inject values from other scopes I find that using application scope will require synchronizing my components, which is definitely not good. I am starting to lean towards using Stateless or the default Event scope for my components. While the new object creation is not ideal it is still better than session scope and avoids potential problems with using application scope. The app won't be under heavy load so the object creation shouldnt be a problem and if it becomes one I can convince them to switch to SLSBs.Anyone have thoughts?