The current aries jpa (master) works quite well with updates of the
persistence unit bundles.
In the 1.x aries jpa I was never able to do a successful update because
of this issue https://issues.apache.org/jira/browse/ARIES-1270 .
In the new version the EntityManagers are closed after each request. If
the persistence unit bundle is updated then the old EntityManagerFactory
is unpublished and closed as soon as all EntityManagers are closed. At
the same time a new EntityManagerFactory is published that will be
picked up for any new transactions.
So the implementation should not need Quiesce to be able to cope with
updates.
Additionally we still have the blueprint quiesce which will shut down
all blueprint services that are the entry point for the acceses to jpa.
So if you do a blueprint quiesce there should be no open EntityManager
instances after a short period anyway.
So with those two mechanisms I think there is no need to implement
Quiesce in aries jpa 2.0 without loosing functionality.
Besides that I have created a 1.x branch. So we will be able to maintain
the old style bundles if people do not want to switch.
The last argument is that the current implementation largely works
without proxies of the EMF and EM. So it is a lot easier to understand
and there is less room for problems. If we would implement Quiesce then
we probably would have to introduce such proxies again with all the
problems they bring.
Christian
On 18.06.2015 15:19, Jeremy Hughes wrote:
Hi Sebastian, I guess I wasn't watching when the discussion happened
in April - sorry about that. We had a discussion before then about the
quiesce scenario with JPA. I see that the quiesce modules are no
longer used by JPA. Can you describe how quiesce is now achieved in
the new implementation. Without it, ie removing something users rely
on, I'd be a -1 on this release.
Thanks,
Jeremy
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
