[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] question about composite persistence unit
|
Comments inline:
On 08/03/2012 9:28 AM, Geronimo Ma. Hernandez wrote:
Hi,
On Wednesday 07 March 2012 - 14:57:26, Tom Ware wrote:
On 06/03/2012 11:27 PM, Geronimo Ma. Hernandez wrote:
What I am hoping to do in this thread is help you get going without such an
extension ...
Yes, I understand your intention and I appreciate it a lot.
... since even in the best case, it will be some time before we can
implement such an extension.
That's no problem at all, as I do some research on a prototype ...
The situation I imagine is one where you have a default persistence unit
that lists your base classes. When you want to extend your persistence
unit, you call refreshMetadata(Properties) and include a property that
points at a way to get an orm.xml file.
Ok, but what if I have 5 completely independent plugins, that all provide
entity classes. Using a map (properties), I can reference only one orm.xml
file.
It is not clear to me how this is different from what you are asking. Please
provide an explanation of that in your enhancement request.
It might for sure be, that I don't know enuf of eclipselink to answer this
question.
From my point of understanding I can provide a orm-file, but what shall I do on
activation of the second or third extension?
I'd like to use a way to extend my app, that is not limited to any number of
plugins ...
If there is a singleton - let's call it EntityRegistry - that I publish from
base app to all plugins.
So each time a plugin with new entities gets activated, the plugin can
register its entities to the central registry (and the registry can manage 2
timestamps - one for last call of refreshMetaData and one for last update of
entitylist).
Each time I use an EntityManager, I could check the timestamps if a refresh is
needed.
Don't know, whether that behavior is already possible with current
implementation.
I agree, providing a single xml file does not solve this issue for multiple
plugins. BTW: I'm not sure if I saw the answer to this earlier, but, are there
relationships between your plugins? (i.e. is there any reason why they can't
just be separate EntityManagers?)
I am not sure what you mean by injecting a provider, but another option in
the refreshMetadata(Properties) call is providing the classname of a class
that is called to get the new metadata. That class is a class you
implement yourself.
From my understanding this ends up at the same problem, than by using a
properties parameter - I can provide only one orm.xml description and I have
one for each activated plugin, that provides entities.
At the moment, I think the way you would support multiple plugins would be to
implement some logic in your MetadataRepository class that would aggregate
information that would be in all the plugins and supply the aggregated file.
I additionally vote for extending the EntityManager to allow the usage of
ConnectionPools in Client-environments too.
In RCP-apps it would be very nice, if a long running persistence job
could be run in background and the app continue without any
restrictions.
EntityManager does allow the use of connection pools. EntityManager is
analagous to our ClientSession. A ClientSession does all its database
access through a ServerSession. The ServerSession supports connection
pooling. EntityManager/ClientSession never access the database directly.
May be I'm blind. I skimmed the available docs for information about
configuration and didn't find some - could you give me a sample on how I have to
setup my Richclient-Configuration to be able to use pooling connections?
An EntityManagerFactory uses a connection pool by default. When you specify a
RESOURCE_LOCAL persistence unit, it uses an EclipseLink-defined connection pool.
When using JTA, you can point at an external connection pool implementation.
What symptom are you seeing that indicates you are not getting pooling?
-Tom
kind regards
Gero
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
