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
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.
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.
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.
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.
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.
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,