my dog learned polymorphism*
The moose likes EJB and other Java EE Technologies and the fly likes Extended PersistenceContext on SFSB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCA/OCP Java SE 7 Programmer I & II Study Guide this week in the OCPJP forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Extended PersistenceContext on SFSB" Watch "Extended PersistenceContext on SFSB" New topic
Author

Extended PersistenceContext on SFSB

Morten Franorge
Ranch Hand

Joined: Jul 29, 2005
Posts: 137
Hi,

I have a question about extended persistence context on a SFSB.
If I have a SFSB that's only purpose is to store session(instance) variables. All data retrieval and persistence is done by calling SLSB.

Example:



As you can see, the SFSB doesn't use the entityManager, but as the Extended persistence context can only be set on a SFSB (and rightly so) I have to include the entitymanager in the SFSB to get the extended persistence context propogated to the SLSB.

Is this correct? Or is there another way to get the extended persistence context propogated to the slsb, without having do declare a entitymanager in my sfsb that is never used?


SCJP 1.4, SCBCD 1.3, SCBCD 5.0, SCEA J2EE, SCEA 5.0
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17258
    
    6

Well, no.

Here is the problem, an extended Persistence Context in a stateless session bean does not make sense, after the first call the bean goes back to the pool and any other client could get it next, and your one client has no guarantees that the next call to the stateless session bean will even go to the same one.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Morten Franorge
Ranch Hand

Joined: Jul 29, 2005
Posts: 137
Originally posted by Mark Spritzler:
Well, no.

Here is the problem, an extended Persistence Context in a stateless session bean does not make sense, after the first call the bean goes back to the pool and any other client could get it next, and your one client has no guarantees that the next call to the stateless session bean will even go to the same one.

Mark


I am well aware of that. I do however find it strange that I have to declare a EntityManager in my SFSB with PersistenceContext type=EXTENDED that I will never use, just to get the extended tx context propagated to the SLSBs
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17258
    
    6

I think simply because there is no way for the spec/container to know who the SFSB's client is going to be. So there is a begin and an end to the SFSB right, and therefore it is "extended" to be there for the beginning to the end, which is assumed to be more than one request.

Mark
Morten Franorge
Ranch Hand

Joined: Jul 29, 2005
Posts: 137
Originally posted by Mark Spritzler:
I think simply because there is no way for the spec/container to know who the SFSB's client is going to be. So there is a begin and an end to the SFSB right, and therefore it is "extended" to be there for the beginning to the end, which is assumed to be more than one request.

Mark


Sure, I know how it works. My problem is that I have a entityManager variable that is never used. There ought to be possible to set @PersistenContext(typeEXTENDED) without an entityManager variable
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17258
    
    6

I think I am missing something here.

OK, so remove the Entity Manager from the Stateful Session Bean if you don't use it there. But are you really not using it, or is there really some lazy initialized stuff that needs that entityManager so you don't get LazyInitialization Exceptions.?

I think you are asking the spec to try and guess what you want to do, and what you sound like you want is something that is rare.

Mark
Morten Franorge
Ranch Hand

Joined: Jul 29, 2005
Posts: 137
As you can see in my example in the first post, the entityManager in the SFSB isn't really used by the code. It does however need to be there, to have the persistence context propagated to the SLSB it's calling.

See?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17258
    
    6

Ok so your use cases call the Stateful Session Bean, which calls the Stateless Session Bean.

In some of my designs, I have DAO classes that are POJOs, not any kind of EJB, so in that Pojo, I have a setEntityManager method to pass the entity manager down.

Mark
Edvins Reisons
Ranch Hand

Joined: Dec 11, 2006
Posts: 364
Morten,

I find your code sample confusing: the setCustomerId() method does not set, as one might expect from its name, the id field in the customer entity, which leaves me guessing about the purpose of the code. Depending on which guess corresponds to your intentions, I see two possibilities:

1. If the top SFSB only takes a (detached) copy of Customer entity, you don't need any, and in particular extended, persistence context for it.

2. If you do use a managed Customer entity in the SFSB, you need the entity manager to manage it
[ December 19, 2006: Message edited by: Edvins Reisons ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Extended PersistenceContext on SFSB