Bugzilla – Full Text Bug Listing
| Summary: | EntityManagerFactoryBuilder to create more than one EntityManagerFactory | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] Gemini.JPA | Reporter: | Missing name <ephikles> | ||||||
| Component: | Core | Assignee: | Michael Keith <michael.keith> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | cvgaviao, eduard.bartsch, edufrazao, gunnar, juergen.kissner, laeubi, nepomuk.seiler, shaun.smith, xu.xiang | ||||||
| Version: | 1.0.0 | Flags: | michael.keith:
iplog+
|
||||||
| Target Milestone: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| URL: | http://www.eclipse.org/forums/index.php/m/699026/ | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Missing name
This enhancement will be added when the EclipseLink bug #352506 is addressed. (In reply to comment #1) > This enhancement will be added when the EclipseLink bug #352506 is addressed. Actually, EclipseLink is capable of providing/handling multiple EntityManagerFactory instances for the same persistence unit without creation of new PUs. Subsequent calls to Persistence.createEntityManagerFactory(puName,props) with different JDBC URL and username/pwd will create multiple EMF instances that point to different databases or DB users. Internally, EclipseLink uses a concept of DB sessions that are differentiated by unique keys like <PU_Name>_nonJtaDataSource=<DS_ID>_url=<JDBC_URL>_user=<JDBC_USER> that include persistent unit name, datasource, JDBC URL and JDBC user. I will attach a patch to Gemini JPA that demonstrates how this EclipseLink feature can be enabled with Gemini JPA for incomplete persistence units. Created attachment 200150 [details]
Gemini JPA patch that uses EL feature for multiple EMFs per PU
Here is the promised patch that patches Gemini JPA and adds a test class that checks that two EMFs for the same PU really work with different DBs.
wow..hey, i depended on you guys stalling me for a couple of days, but now it seems like i have to get back to do some actual work again ;) no, just kiddin'.. works like a charm on first glance. now i gotta fit it into my whole datasource- and emf-creation logic. thanks alot!! f. > Actually, EclipseLink is capable of providing/handling multiple
> EntityManagerFactory instances for the same persistence unit without creation
> of new PUs.
Yes, thanks for bringing this up. I'm aware of what EclipseLink can do, but this is a misfeature and completely breaks the JPA persistence unit model. Having multiple logical persistence units of the same name but configured differently is incorrect and not something that I will want to support in Gemini JPA. The proper way is to do as I suggested and create a new persistence unit. I know it will be easy precisely because EclipseLink already can create a new ServerSession (EMF-level db connections and cache) on demand.
Somehow I feared you'd say something like that. Well, I suppose I will take Eduard's patch as an interim solution until the clean and good one is out.. I expected it somehow as well. My fix is simple but it resides in the gray zone beyond the spec. So if we have a chance to get a JPA spec compliant solution soon it would be the best. Let's continue the discussion on bug #352506 since I have some questions about the solution. *** Bug 365833 has been marked as a duplicate of this bug. *** (In reply to comment #5) > > Actually, EclipseLink is capable of providing/handling multiple > > EntityManagerFactory instances for the same persistence unit without creation > > of new PUs. > > Yes, thanks for bringing this up. I'm aware of what EclipseLink can do, but > this is a misfeature and completely breaks the JPA persistence unit model. FWIW, I applied the patch to latest Gemini and modified it to check for the "eclipselink.session-name" property. This property was recommended to me as the proper way of enabling multiple schema based multi-tenancy in EclipseLink. Given that this is a rare use-case I wonder why it's not ok to apply this patch which requires a property to be set. Users of this property likely know the consequences. Multi-tenancy is a nice feature of EclipseLink and allowing Gemini JPA to support this without a lot overhead (eg. creating dummy PUs) doesn't sound too bad. Created attachment 208367 [details]
Slightly updated patch to also check for EclipseLink session name property
Mike, from your descriptions is looks like that that your preferred solution requires more time to implement and won't be available soon. Sorry if I may sound impatient. But we'd like to start shipping a Gemini JPA/EclipseLink integration together with our Eclipse project soon. The attached patch runs fine. The only option I see currently is delivering the patch by myself which I really don't like to do. Is there any chance we can have a workable solution for that issue soon which won't require to ship a patched version? I can look at supporting this solution temporarily, requiring a property, and with a warning that it is only for certain use cases. Thanks a lot Mike! Hi all! First of all, thanks a lot for the patches provided here. My scenario is exactly as Gunnar has mentioned. I'm using Eclipselink 2.3.x with Virgo, with a dynamic multitenant properties. I need to use a Shared EntityManager Factory per application logged tentant, so, the second patch was my only solution. (And it works very well, thanks!!) As Eclipselink multitenant documentation says: -- Entity Manager Factory At this level, users will be required to provide a unique session name through the "eclipselink.session-name" property to ensure a unique server session (and cache) is provided for each tenant. This allows for user defined properties (without any prefixing) (http://wiki.eclipse.org/EclipseLink/Development/Indigo/Multi-Tenancy) -- So, it will be great if Gemini JPA includes this change in the default destribuition, as it is designed to work with Eclipselink. Thanks by all effort! Att, Eduardo Frazão Okay, by popular demand I will add/enable this feature now and document it accordingly. Thanks, everyone, for your input. I want to thank you for the effort and agility. Pushed to repo. *** Bug 366622 has been marked as a duplicate of this bug. *** |