Thank you.
Before filling an issue, I would like to know if this programming
pattern is supported by TopLink and/or it's is (or isn't) a good practice:
1) Whenever I need a EntityManager, I ask to a utility class (as per
pattern definition of utility class) that have a method like:
public static EntityManager getEM() {
return getFactory().createEntityManager();
}
private static EntityManagerFactory getFactory() {
if(emF==null) {
try {
emF = Persistence.createEntityManagerFactory("GeDoc2PU");
} catch(Exception ex) {
ex.printStackTrace();
}
}
return emF;
}
where emF is a private static EntityManagerFactory.
(I do that to avoid object proliferation on the server side, since I can
have lot's of users doing thousands of requests simultaneously).
So using this pattern, I have only one EntityManagerFactory for that
classloader (AFAIK, that's the logic behind). Or should I have one
EntityManagerFactory created every time?
2) Classes that manipulate the entities use "Singleton" pattern, for
example, to store a customer in database, I just call:
CustomerBroker.getInstance().store(oneCustomer);
So, there is only one instance of CustomerBroker per classloader (at
least, it's what I suppose to).
Someone that knows a little more than me about Servers, Classloaders and
JPA could clarify if this could be the cause of the problem, and what
would be best solution (for example, always creating a
EntityManagerFactory and leading to TopLink to manage how many instances
will have?!).
Regards,
Edson Richter
glassfish_at_javadesktop.org escreveu:
> >From a Java EE perspective there is nothing wrong with having two different applications that
> each contain a PU of the same name. PU names are never scoped outside of the application in
> which they are defined so there shouldn't be any clashing. It's possible it's a bug. Please file
> a bug report detailing the error and if possible including the application itself.
> [Message sent by forum member 'ksak' (ksak)]
>
> http://forums.java.net/jive/thread.jspa?messageID=223082
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>
>