Create and Destroy component versus Session scope

[cash1981]

I have a JavaBean with lots of listeners that are fired quite frequently. Its a system log component.

If I change the JavaBean to a STSB, and increase scope to Session, will it increase performance so that it wont create and destroy the component so frequently? Or is the creation and destroying of components a quick task and really nothing to gain? How much faster will it be if I create a stateless service instead of javabean?

[norman]

If it's truly stateless with no seam-managed injection then you could create a single application-scoped instance if you wanted.  In general, I wouldn't worry much about it unless you observe a performance problem.

[cash1981]

Well, I inject EntityManager and the CurrentUser, so I think I need to have session scope, because of most possibly race conditions if only a single application-scoped instance is created? Anyways seam is slow enough, thats why I want to increase performance where I can :-)

[gonorrhea]

Seam ref doc:

Seam serializes requests to session scope session beans and JavaBeans by default (and detects and breaks any deadlocks that occur). This is not the default behaviour for application scoped components however, since
application scoped components do not usually hold volatile state and because synchronization at
the global level is extremely expensive. However, you can force a serialized threading model on
any session bean or JavaBean component by adding the @Synchronized annotation.

remember that SLSB are pooled transactional components whereas SFSB are not.  so if you have 1000 simultaneous clients accessing the same business logic via SFSB, then 1000 instances of SFSB are spawned (and serialized to disk as required for passivation, etc).  This requires more memory space than 1000 method calls to SLSB which are typically fast in duration and returned back to the pool in the EJB container.

I'm not sure in terms of performance whether SLSB is better than JavaBean as I'm not sure JavaBean are pooled or not.

I may be completely wrong on all this but I believe there are some performance improvements the core team already did in 2.1.2 or 2.1.1 and there may be some improvements coming in EE 6 with JSF 2.0.

However, it would be nice if we could specify which business methods in our Seam components actually require bijection for specific properties.  Currently, Seam executes injection for all injectable properties prior to your business method execution and likewise after successful completion of method call.

Seems like you don't always need all the properties to be injected for every business method.  That may be a small performance optimization, who knows...

[brandonsimpson]

I know it's probably not very popular to say it since @In and @Out are sort of major features of Seam, but to me they just seem to be too inefficient for me to want to use them in an application where performance really matters. It's just like you said...using the bijection all the time seems to do a lot of unnecessary work in many cases where you have several methods on an object and not all the @Ins and @Outs are needed. I also don't really like @Out because I feel like I'm exposing all these things globally that didn't need to be exposed. It feels like a step backwards in software development moving away from encapsulation. When I was reading about Seam I was like Oh...that's cool! on everything, but now that I'm developing a real world application, I'm doing a lot more thinking about the implications of each feature.

[gonorrhea]

I'm not sure of the details of Guice in JCDI (Web Beans) and Seam 3, but we'll see how bijection may or may not change.  I believe Guice is type-safe whereas currently Seam bijection is not.

There was a recent thread on this forum discussing avoiding excessive bijection (as recommended by PMuir initially).

Remember you can outject (or inject) to a particular scope if needed, but you can't restrict the outjection in that particular context to a particular set of Seam components.

In other words, the following is not possible:

@Out(required = false, scope=ScopeType.SESSION, _component=foo_)
private String bar;

Perhaps the counter argument to this idea is why would you ever need to do that?  If the context variable needs to be stored in HttpSession space, then that memory space will be taken either way, whether you identify a specific component that may inject it or not.

I think the more important optimization may be not injecting all context variables marked with @In prior to a business method execution.  Specifying which injections that should occur for each business method may be advantageous in some cases.  But it's also more code/work.

The supposed problem with excessive outjection is that it reduces loose coupling of your components...

[gonorrhea]

I just realized something.  How do you specify more than one value for an element in an annotation.

For the following, for example, how would you specify multiple components?  Do annotations in EE 5 or EE 6 support this?  It seems to me all EE 5 and Seam annotations are 1:1 ratio b/n element and value in annotation.

@Out(required = false, scope=ScopeType.SESSION, _component=foo_)
private String bar;

[gonorrhea]

nevermind, apparently this is the syntax:

@Constraint(validatedBy = {
     SizeValidatorForString.class,
        SizeValidatorForCollection.class } )