Currently we are building web services applications with Spring, Hibernate, MySQL and tomcat. We are not using real application server- SoA architecture. Regarding the persistence layer – today we are using Hibernate with MySQL but after one year we may end up with MongoDB and Morphia.
The idea here is to create architecture of the system regardless concrete database engine or persistence layer and get maximum benefits.
Let me explain – https://s3.amazonaws.com/creately-published/gtp2dsmt1. We have two cases here:
Scenario one:
We have one database that is replicated (in the beginning no) and different applications. Each application represents on war that has it’s one controllers, application context, servlet xml. Domain and persistence layer is imported as maven lib – there is one version for it that is included in each application.
Pros:
- Small applications that are easy to maintain
- Distributed solution – each application can be moved to it’s own tomcat instance or different machine for example
Cons:
- Possible problems when using hibernate session and sync of it between different applications. I don’t know that is possible at all with that implementation.
Scenario two – one application that has internal logic to split and organize different services – News and User.
Pros:
- One persistence layer – full featured of hibernate
- More j2ee look with options to extend to next level- integrate EJB and move to application server
Cons:
- One huge war application more efforts to maintain
- Not distribute as in the first scenario
I like more the first scenario but I’m worried about Hibernate behavior in that case and all benefits that I can get from it.
I’ll be very thankful for your opinion on that case.
Cheers
There are a couple of solutions that solve this exact problem:
Terracotta
Take a look at Hibernate Distributed Cache Tutorial
Also there is a bit older slide share Scaling Hibernate with Terracotta that delivers the point in pictures
Infinispan
Take a look at Using Infinispan as JPA-Hibernate Second Level Cache Provider
Going with the first solution (distributed) may be the right way to go.
It all depends on what the business problem is
Of course
distributedis cool and fault tolerant and, and,.. but RAM and disks are getting cheaper and cheaper, so "scaling up" (and having a couple hot hot replicas) is actually NOT all that bad => these are props to the the "second" approach you described.But let’s say you go with the approach #1. If you do that, you would benefit from switching to NoSQL in the future, since you now have replica sets / sharding, etc.. and actually several nodes to support the concept.
But.. is 100% consistency something that a must have? ( e.g. does the product has to do with money ). How big are you planning to become => are you ready to maintain hundreds of servers? Do you have complex aggregate queries that need to run faster than xteen hours?
These are the questions that, in addition to your understanding of the business, should help you land on #1 or #2.