Our application is a middle-tier application that provides a dozen or so front-end application with access to a couple dozen databases (and other data sources) on the back end.
We decided on using OSGi to separate the unrelated bits of code into separate bundles. This ensures proper code encapsulation and even allows for hot-swapping of specific bundles.
One advantage of this is that any code speaking to a specific database is isolated to a single bundle. It also allows us to simply drop in a new bundle for a new destination, and seamlessly integrates the new code. It also ensures that if a single back-end data source is down, that requests to other data sources are unaffected. One complication is that each of those bundles is loaded by a separate ClassLoader.
We'd like to start using JPA for our new destinations that we're building. Previously, we have been using JDBC directly to send SQL queries and updates.
We've looked into Hibernate 4, but it seems that it was built on the assumption that everything is loaded using a single ClassLoader. Switching between ClassLoaders for different bundles does not appear to be something it can handle consistently.
While it seems that Hibernate 5 may have corrected that issue, all the tutorials/documentation I've found for it gloss over the complexities of configuration. Most simply assume you are using a single application-level configuration file, which will not suit our needs at all.
So, my questions are:
Does Hibernate 5 properly handle connecting to multiple databases, with the configuration/POJos for each database loaded by a different ClassLoader?
How do we configure Hibernate to connect to multiple databases using multiple ClassLoaders?
Is there another JPA framework that might be better suited to our specific needs?
Hibernate is fine but for OSGi usage you also need an intermediary. In the OSGi specs this is defined by the OSGi JPA service spec. It defines how to connect to a JPA provider in OSGi without a hard reference to it.
This spec is implemented by Aries JPA. It also provides additional support for blueprint and declarative services. There is also Aries transaction control service that takes similar approach to supporting JPA and transactions in OSGi it also uses the core of Aries JPA but is a bit different in usage.
The last part you might need is pax-jdbc which allows to define a XA datasource just with configuration. The examples already use it.
To get started easily you can use Apache Karaf which has features for all of the above.
Aries JPA allows to use different databases in the same OSGi application.
Related
There are two projects that talk to the same database (but to different tables) in JPA. One with Hibernate (plus some Spring), one with EclipseLink. Projects have to be merged: one must now call the other.
Both have a persistence.xml configuration, but with vendor-specific flags. Merging both persistence.xml has not been successful as you can imagine. Refactoring one project is out of the question.
I was wondering if one could stop relying on JPA (to avoid the persistence.xml conflict) but still get something with Persistence.createEntityManagerFactory, and have that be compatible with annotated #javax.persistence.Entitys.
No, you cannot (easily) "stop relying on JPA". JPA is an API, that is the list of classes and methods that your application uses to talk to the databases. Not using JPA would mean completely rewriting your database layer, which you presumably want to avoid.
However, you can continue using the two persistence.xmls side by side (possibly merged into one file). To do this, you would maintain two JPA persistence contexts in parallel, meaning you would have two different EntityManagerFactorys in your code for the different parts of your (merged) application.
This will sometimes make life a bit more complicated, because things like Spring integration of JPA usually assume there is only one persistence context, but it should be doable.
While your case seems rather unique, one common reason to have multiple persistence contexts in parallel is when you need to access multiple databases from one application. See for example persistence.xml for multiple persistence units for how this can work.
In principle, this will also work if the two persistence contexts access the same database. You'll just need to be careful with caching in JPA, because that usually assumes noone else is writing to the database. However, if your two persistence contexts never operate on the same table, that should be no problem.
Try using two persistence units in parallel, and if you get stuck, ask a new question :-).
I am trying to develop a java software based on OSGi (Apache Felix), which different module (which may contain more than one jar file) could be developed by different developers from different companies.
the question is: i am wondering how should i provide database connection to these modules. if i share the same user credential between modules, they may accidentally or intentionally use each other tables or data which should be avoid because of information privacy. or if i force each module to have its own connection with its own user credential then there will be many connections.
note: i am using mariadb as backend.
i know this problem is not a OSGi specific problem. i am wondering if anyone has faced such problem and has proven solution for this scenario (i only describe my development environment).
any idea,
thanks
First of all, your issue of multi-tenancy isn't something any system (beeing it OSGi or not) is made for. Therefore you need to take care of this yourself. Most OSGi applications still use datasources if you want to connect to a db, via JPA for example. Usually those datasources are registered as OSGi services.
Coming back to your multi-tenancy issue, you should make sure for each you have another datasource and just use that datasource in your application. For example make sure each tenant has it's own configuration and therefore receives his own Datasource as configured in your configuration. This way you can make sure each tenant is separate to each other.
OSGi cannot achieve the level of security you need for this scenario. An OSGi Framework is intended to represent a single logical application. If bundles exist in the same JVM and OSGi Framework, then it is very hard to prevent data leaks, especially against determined attacker.
You need to isolate processes at the very least, and run those processes as separate user IDs.
I am trying to create web application that allow its users to create new forms and tables (many ERP applications have such feature). It is clear about generating and saving HTML forms and it is clear about generating new tables in database as well. But what about entities, e.g. Spring #Entity and #Repository classes.
One can try to compile then on the fly and save into the web application deployment directory, that should be possible. But is there need to update some kind of internal Spring registry of existing beans, repositories and controllers. Does Java JPA have such registry as well?
Is it possible to do such kind of thing? It is clear that it is possible to do this in php, e.g. to dynamically update yii framework application, because there is no compiled code (except, maybe, cached code) and with each new request the available paths are scanned anew. But how this happens in Enterprise Java and Spring applications?
Maybe I should look for Groovy Grails or Scala Play - they may be more dynamic languages.
More "object java storages" compatible with JPA (ObjectDB and Co) promise smoother, more natural migration with extra fields and classes. I haven't personal opinion.
EDIT: good perspective has, I think, philosophy ActiveRecord and similar. Few solutions in Java are ready. I have tried such solutions with partial success, but my project was not too dynamic (classes were stable) and we switched to clear JPA.
some ERP applications (in different languages f.e.C,Java.C#) have an idea "kernel class and additional fields", ie. Customer with all typical fields plus "Preffered color" (usually implemented in extra hidden tables). This is OK if they don't need new relations
Eclipselink has similar concept 'extra fields' in JPA area (not strict standard JPA but extension) https://wiki.eclipse.org/EclipseLink/Examples/JPA/Dynamic
At project level, seems to be OK enter non-critical data
3 Ist hard to imagine create high count of dynamic important/central classes (tables) without radically redesigned application (proverbially version 2.0 ;) )
Sometimes I try stop and restart EMFactory with different Persistence Units (in Tomcat environment) with Hibernate and Eslipselink, but not use in production. Reset & start seems be ok, this is like rupture and new life of JPA engine. Its more like application 2.0 than small patch.
Creating multiple gemmini table sets (for different companies in the same database) is good in Hibertate and Eslipselink (prefix before table name), few dedicated lines by start, normal clean JPA use. Tested, all OK.
Once again, adding single/few tables is poorly reworked in the community.
It is an interesting discussion to "glue" together common JPA modules (code+JPA), this is done often by OSGI programmers.
Theoretically so it has to module give your tables, strongly connected in the same PU.
At the ERP application level it can be anything from "add CRM module" to "kernel + sales".
I'm an interested spectator, but i have not seen any success.
If you look in the google integrate persistence unit from parts, composite persistence unit, many programers try to reach such target.
It is like a fishing rod rather than fish (as the old adage goes).
Persistence Unit conception isn't friendly for such ideas (and is blocked in standard JPA).
I'm developing a Java EE application to run on Glassfish:
Database (javaDB, MS SQL, MySQL or Oracle)
EJB layer with JPA (Toplink essentials - from Glassfish) for
database access
JSF/Icefaces based web UI accessing the EJB layer
The application will have a lot of concurrent web client, so I want to
run it on different physical servers and use a load-balancer. My
problem is now how to keep the applications synchronized. I intend to
set up multiple servers, each running Glassfish with my EAR app
installed. Whenever on one of the servers data is added to or removed
from the database (via JPA, no direct SQL queries), this change should
be reflected in the JPA layer on the other servers.
I've been looking
around for solutions to this, but couldn't find anything I really like
(the full Toplink from Oracle claims to have a solution, but don't
know). Doing a refresh before every access to a JPA entity could work,
but is far from efficient.
Are there any patterns, libraries, ... that could help here?
Whenever on one of the servers data is added to or removed from the database (via JPA, no direct SQL queries), this change should be reflected in the JPA layer on the other servers.
I don't understand what state is maintained and need to be updated at the "JPA layer". Entity managers are isolated and the way to deal with concurrency in JPA is to use locking (optimistic or pessimistic, the former scaling better). Maybe you could clarify what you need exactly and what you saw.
See also
Java Persistence/Locking
We currently have a web application loading a Spring application context which instantiates a stack of business objects, DAO objects and Hibernate. We would like to share this stack with another web application, to avoid having multiple instances of the same objects.
We have looked into several approaches; exposing the objects using JMX or JNDI, or using EJB3.
The different approaches all have their issues, and we are looking for a lightweight method.
Any suggestions on how to solve this?
Edit: I have received comments requesting me to elaborate a bit, so here goes:
The main problem we want to solve is that we want to have only one instance of Hibernate. This is due to problems with invalidation of Hibernate's 2nd level cache when running several client applications working with the same datasource. Also, the business/DAO/Hibernate stack is growing rather large, so not duplicating it just makes more sense.
First, we tried to look at how the business layer alone could be exposed to other web apps, and Spring offers JMX wrapping at the price of a tiny amount of XML. However, we were unable to bind the JMX entities to the JNDI tree, so we couldn't lookup the objects from the web apps.
Then we tried binding the business layer directly to JNDI. Although Spring didn't offer any method for this, using JNDITemplate to bind them was also trivial. But this led to several new problems: 1) Security manager denies access to RMI classloader, so the client failed once we tried to invoke methods on the JNDI resource. 2) Once the security issues were resolved, JBoss threw IllegalArgumentException: object is not an instance of declaring class. A bit of reading reveals that we need stub implementations for the JNDI resources, but this seems like a lot of hassle (perhaps Spring can help us?)
We haven't looked too much into EJB yet, but after the first two tries I'm wondering if what we're trying to achieve is at all possible.
To sum up what we're trying to achieve: One JBoss instance, several web apps utilizing one stack of business objects on top of DAO layer and Hibernate.
Best regards,
Nils
Are the web applications deployed on the same server?
I can't speak for Spring, but it is straightforward to move your business logic in to the EJB tier using Session Beans.
The application organization is straight forward. The Logic goes in to Session Beans, and these Session Beans are bundled within a single jar as an Java EE artifact with a ejb-jar.xml file (in EJB3, this will likely be practically empty).
Then bundle you Entity classes in to a seperate jar file.
Next, you will build each web app in to their own WAR file.
Finally, all of the jars and the wars are bundled in to a Java EE EAR, with the associated application.xml file (again, this will likely be quite minimal, simply enumerating the jars in the EAR).
This EAR is deployed wholesale to the app server.
Each WAR is effectively independent -- their own sessions, there own context paths, etc. But they share the common EJB back end, so you have only a single 2nd level cache.
You also use local references and calling semantic to talk to the EJBs since they're in the same server. No need for remote calls here.
I think this solves quite well the issue you're having, and its is quite straightforward in Java EE 5 with EJB 3.
Also, you can still use Spring for much of your work, as I understand, but I'm not a Spring person so I can not speak to the details.
What about spring parentContext?
Check out this article:
http://springtips.blogspot.com/2007/06/using-shared-parent-application-context.html
Terracotta might be a good fit here (disclosure: I am a developer for Terracotta). Terracotta transparently clusters Java objects at the JVM level, and integrates with both Spring and Hibernate. It is free and open source.
As you said, the problem of more than one client web app using an L2 cache is keeping those caches in synch. With Terracotta you can cluster a single Hibernate L2 cache. Each client node works with it's copy of that clustered cache, and Terracotta keeps it in synch. This link explains more.
As for your business objects, you can use Terracotta's Spring integration to cluster your beans - each web app can share clustered bean instances, and Terracotta keeps the clustered state in synch transparently.
Actually, if you want a lightweight solution and don't need transactions or clustering just use Spring support for RMI. It allows to expose Spring beans remotely using simple annotations in the latest versions. See http://static.springframework.org/spring/docs/2.0.x/reference/remoting.html.
You should take a look at the Terracotta Reference Web Application - Examinator. It has most of the components you are looking for - it's got Hibernate, JPA, and Spring with a MySQL backend.
It's been pre-tuned to scale up to 16 nodes, 20k concurrent users.
Check it out here: http://reference.terracotta.org/examinator
Thank you for your answers so far. We're still not quite there, but we have tried a few things now and see things more clearly. Here's a short update:
The solution which appears to be the most viable is EJB. However, this will require some amount of changes in our code, so we're not going to fully implement that solution right now. I'm almost surprised that we haven't been able to find some Spring feature to help us out here.
We have also tried the JNDI route, which ends with the need for stubs for all shared interfaces. This feels like a lot of hassle, considering that everything is on the same server anyway.
Yesterday, we had a small break through with JMX. Although JMX is definately not meant for this kind of use, we have proven that it can be done - with no code changes and a minimal amount of XML (a big Thank You to Spring for MBeanExporter and MBeanProxyFactoryBean). The major drawbacks to this method are performance and the fact that our domain classes must be shared through JBoss' server/lib folder. I.e., we have to remove some dependencies from our WARs and move them to server/lib, else we get ClassCastException when the business layer returns objects from our own domain model. I fully understand why this happens, but it is not ideal for what we're trying to achieve.
I thought it was time for a little update, because what appears to be the best solution will take some time to implement. I'll post our findings here once we've done that job.
Spring does have an integration point that might be of interest to you: EJB 3 injection nterceptor. This enables you to access spring beans from EJBs.
I'm not really sure what you are trying to solve; at the end of the day each jvm will either have replicated instances of the objects, or stubs representing objects existing on another (logical) server.
You could, setup a third 'business logic' server that has a remote api which your two web apps could call. The typical solution is to use EJB, but I think spring has remoting options built into its stack.
The other option is to use some form of shared cache architecture... which will synchronize object changes between the servers, but you still have two sets of instances.
Take a look at JBossCache. It allows you to easily share/replicate maps of data between mulitple JVM instances (same box or different). It is easy to use and has lots of wire level protocol options (TCP, UDP Multicast, etc.).