Hi David,
On Aug 24, 2006, at 9:41 PM, David Jencks wrote:
I've been looking at the ejb 3 persistence spec and it looks to me
as if there are some poorly explained bits.
That is certainly the case.
Anyone have any clues about these or any clue about where I could
get an answer?
1. The @PersistenceContext annotation appears to be per jee
component (web app or ejb). You can specify a map of properties to
pass in to the EMF.createPersistenceContext method. Lets suppose
you have tx scoped PC, and you have 2 ejbs with tx Required and one
calls the other, and one specifies a map of properties and the
other doesn't (or they specify different maps). What's supposed to
happen?
I guess propagation of context within a transaction takes precedence
over property overrides:
Section 5.8.2: "If a persistence context is already associated with
a JTA transaction, the container uses that persistence
context for subsequent invocations within the scope of that
transaction, according to the semantics for
persistence context propagation defined in section 5.6.3."
2. What's supposed to happen when you try to use a CM tx scoped EM
outside a JTA tx? Section 5.6.1 seems to imply we aren't supposed
to just throw an exception, but section 5.9.1 seems to imply there
is no provider EM in back of the CM EM to do any work without a JTA
tx. Are we supposed to create and close a provider EM for each
call outside a tx?
Good question... I have no idea.
- How heavyweight are EntityManagers?
I guess this could be implementation specific, but they are
lightweight in Cayenne, and I assume they are lightweight in other
providers as well.
Is it more efficient to create a new one or pool them?
While the spec provides some leeway (see below), container with
pluggable provider has no way of knowing the best strategy. My vote
is to avoid pooling EntityManagers by default.
Section 5.8.2: "It is undefined whether a new entity manager instance
is created for every persistence context, or whether entity manager
instances are sometimes reused. Exactly how the container maintains
the association between persistence context and JTA transaction is
not defined."
Are they cheap enough so every CM tx-scoped EM can have a "outside
tx" provider EM attached to it in case anyone is dumb enough to do
work outside a tx? Is this more or less resource efficient than
creating a new EM for each out-of-tx use?
Not sure I understand the question.
Andrus
