Injecting a session bean into an application bean

[B Nirvan]

Hi,
I am facing a somewhat odd problem. I have an application scoped managed bean which I have configured as eager load. This bean is used to initialize application (like creating default database records) when the application starts up. The problem is that the application scoped bean needs the services of Session Scoped beans. The container doesn't allow me to inject the Session scope bean into application scoped bean. If I try to load the bean using context.getApplication().evaluateExpressionGet(), I get

    
java.lang.NullPointerException
        at com.sun.faces.mgbean.BeanManager$ScopeManager$SessionScopeHandler.handle(BeanManager.java:571)

How do I use Session scoped managed beans from an application scoped bean. All the beans described above refer to JSF managed beans. I am using JSF 2.0.3 (Mojarra) on glassfish V3.

regards,
Nirvan.

[Ilari Moilanen]

In general you are not allowed to use managed beans that have shorter lifespan than the bean you are calling it from.

For example when you are using application bean are you certain that the session even exists when you try to obtain bean from it? If you do your fetch when application start there are no sessions to fetch beans from! And from what session would you even fetch it? There could be hundreds of sessions if you have hundreds of concurrent users.

[B Nirvan]

Seems quite logical. The issue then is how do I populate default database records. I am using hibernate, and JTA as transaction manager.

regards,
Nirvan

[Tim Holloway]

Actually, you wouldn't want to inject session-scope beans into application scope anyway. There could be as many instances of the session beans as there are users, but there's only one instance of the application scope bean to inject them all into!

If you're looking to hold global information obtained from a database (one of my favorites is the labels in dropdown lists), application-scope objects can do that just as well as session-scope objects. When using Spring+Hibernate in my projects, you actually couldn't tell just by looking what the scope was based solely on how the persistent data was obtained.

[B Nirvan]

Tim I get the point, but what I am looking for is creating default administrator records in database. It can be done by running a database script, but since I am using hibernate I am trying to avoid direct table access.

Actually, I can use hibernate entiity manager and Usertransaction in my application scoped bean (created specially for the inserting admin records in database), but I am not sure of the implications of injecting PersistentContext and UserTransaction in an application scoped beans. Since the application scoped bean remains till the application is running, what happens to the injected PersistentContext. Will it be ok to inject the PersistentContext or I should avoid it alltogether.

regards,
Nirvan.

[Tim Holloway]

I do this all the time, but I'm using Hibernate JPA, so what I actually inject is a DAO/data service object, not the Hibernate persistence context. The DAO in turn has an entityManager injected into it, but that's just a reference to the master entityManager that Spring created. The actual database connection is only acquired while a transaction is active. It can be (and is) safely released when the transaction ends. I'm using AOP transaction management mostly, but the same rules apply if you manage transactions manually.

It's not generally performant to hit the database for every little thing, so when I pull dropdown menu labels from the persistent store, I acquire a detached copy and cache it in the application-scoped object. Actually, I also build the JSF SelectItem objects for that particular case, since I want as little redundant work as I can spare memory for.

So, as I said, my application scope objects using persistent storage look identical to my session and request scope objects using persistent storage. Except for the scope definition.

[B Nirvan]

Tim Holloway wrote:I do this all the time, but I'm using Hibernate JPA, so what I actually inject is a DAO/data service object, not the Hibernate persistence context. The DAO in turn has an entityManager injected into it, but that's just a reference to the master entityManager that Spring created. The actual database connection is only acquired while a transaction is active. It can be (and is) safely released when the transaction ends. I'm using AOP transaction management mostly, but the same rules apply if you manage transactions manually.

I am too using Hibernate JPA. But I have kept my data service layer as managed bean with session scope. So I am unable to inject the DAO/data service into my application scoped beans. I think I should make the DAO layer as Application Scoped. I hope there won't be any threading issues as the DAO beans do not have any state to store other than EntityManager and UserTransaction(which can be safely shared ). Do you think that high number of concurrent users will degrade the performance of the DAO layer if application scope is used for that layer ?

Tim Holloway wrote:It's not generally performant to hit the database for every little thing, so when I pull dropdown menu labels from the persistent store, I acquire a detached copy and cache it in the application-scoped object. Actually, I also build the JSF SelectItem objects for that particular case, since I want as little redundant work as I can spare memory for.

I am using the same process of loading detached objects and then refreshing cache if any of these objects are added, modified or deleted.

thanks and regards,
Nirvan.

[Tim Holloway]

Actually, my data service objects are "Spring" scoped. That is, they're all singleton objects constructed by Spring and injected into the JSF objects. So they're effectively equivalent to Application scope for most intents and purposes. And because they're stateless objects, they can safely be used at all scopes and in multi-threaded situations. The only real threading issues are in the realm of database transaction management.

[B Nirvan]

Tim,
I have changed my data service layer scope to application. Thanks for being so helpful and sharing your experiences.

regards,
Nirvan