On Oct 31, 2006, at 9:11 AM, Meeraj Kunnumpurath wrote:
Hi,
I have made a start on JPA integration. Haven't got to do much because
of the build problems. The current home is
sca/services/persistence/common.
Anyway, this is a brief highlight of my thinking ...
1. Support injection of entity manager factory and entity manager
instances using PersistenceUnit and PersistenceContext annotations on
member fields.
2. For entity manager factory instances, the unitName attribute is
introspected at the component load time and scans all the available
persistence.xml for matching unit name.
3. The JPA provider API is used for creating the entity manager
factory.
4. Entity manager factory is caches somewhere (System composite)
Yes it would be cached as a system component in the *application*
composite. During processing of the assembly, a AtomicComponent
representing the EMF would be created and registered with
CompositeComponent.register(SCAObject). The JPA
AtomicComponent.isSystem() would return true to indicate to the
application composite that it was a system type. I was thinking this
would be done in an ImplementationProcessor when it encountered a JPA
annotation, where the CompositeComponent is the application composite
passed into the ImplementationProcessor.
5. This is then reused in all the components using the same
persistence
unit.
Persistence context is trickier. Entity manager AFAIK are thread
unsafe
and mostly bound to transactions. Hence, either we will have to proxy
this or use some sort of instance pooling and thread confinement in
our
component management. I think, proxying would be simpler. I plan to
get
at least the EMF side working by end of this week, if I can get the
build going.
I think we could have an implementation processor that creates an
Injector in response to seeing a JPA annotation on a component
implementation. This injector would provide Proxies for injection on
a component implementation instance as you mentioned. The proxy would
have a reference to a JPAAtomicComponent (or whatever it is called)
and would call getServiceInstance(..) during an invocation to
dynamically resolve the correct EntityManager instance for the
transaction (or other Scope). The JPAAtomicComponent in turn would
have a reference to a ScopeContainer which would be responsible for
managing EMF instances. We may need a TransactionScopeContainer for
this that was configured to receive synchronization callbacks from a
JTA transaction manager to flush, close and evict EntityManager
instances.
We could also potentially introduce an optimization when an
EntityManager is injected into a component instance. If the instance
is of a shorter scope than the scope of the EntityManager (e.g.
instance vs. transaction), the actual EntityManager could be injected
as opposed to a proxy. I'm not sure this is worth it though since the
only thing shorter than a transaction is stateless.
Seth, I had a couple of questions related to EntityManager:
1. Should the scope of an entity manager default to a transaction? I
think it would have to to maintain object identity correctly.
2. Would application developers want a longer scope for an entity
manager? For example, in Hibernate there is a concept of an
"application transaction" that may span multiple database
transactions such as a series of screens a user steps through to
complete a task.
Thanks,
Jim
Ta
Meeraj
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
