This is an old post...but my 2 cents:
I think it was answered by Costin. I ran into this issue as well and came across this post, but for a non-web application. If you want to use extended contexts in your DAO, then you must have another object, such as that an object living in the session, that closes the context at a point in time defined by your application. In whatever object that wraps around the DAO method calls, that object would probably receive a EMF versus a EM. You would then create and close the EM base on your applications "conversation" starting and stopping. How you do this will be different for every application and every application type because its completely dependent on your application domain. For many web apps, the "conversation" is a wizard-like series of screens or a set of pages that are related together. You also see alot of the session-in-view discussion around this because that's another common, but still application dependent, scenario.
So if you use extended contexts in your DAOs, some other mechanism must be used to close/flush it when needed. You have to define it and its significantly more careful design work. So if your object graphs are rich with relationships that you must navigate when you want to navigate them, then you have to think more deeply about how the persistent context is used much more carefully. My domain objects have 4-5 levels of objects in them so this issue significantly affects me. In some cases, I have chosen to navigate through DAOs and not always through the object graph directly--more of a hybrid approach--that allows me to use standard transaction persistent contexts more often then not but its more confusing to clients using the code.
This is also why transaction tx:advice is a good answer for you in spring sometimes. Because the transaction semantics may change in different applications and you want to use the same DAOs in multiple places, it may be worth using advice configured in the spring container to set the transaction behavior on methods versus using transaction annotations which lock your transaction semantics directly into your code. In the absolute worse case, your business objects get littered with some transaction semantics but you get exactly what you want--I don't consider that wholly bad if you have something that special.
Quote:
Originally Posted by wanted.alive
