I have to implement a number of activities (for example, update a user's profile, transfer points from one user to another, etc...), each of which can be composed by one or more logical steps (check if user has enough points, subtract points from the first user, check if the other user can receive then, credit these points to the second user) in a given order. I also need to implement some kind of "rollback" mechanism so that I can undo any previous steps if something goes wrong with step N (kind of what one usually foods in database transactions, except for the fact that a database may or may not be involved).
Are there any Java libraries which can help me with this? I've had a look at Drools but it seems overly complex. Also, I'm not sure it supports this kind of rollback mechanism. Any ideas?
The JTA specifications is a framework defining a standard behavior for java transactions.
A typical and well known use case is the simple database transaction, but JTA is far more generic. It's a framework to manage transaction over one or more transactional resource. A transactional resource can be a database of course, but it can also be a file, a messaging service, ...
If you have multiple transactionnal resources implied in one transaction, you must search for a JTA implementation supporting XA-Transactions.(and here is another interesting link about XA)
I don't say that this is a simple framework... but the problem you are facing is not simple at all.
If you've got to integrate with other services/providers through REST/SOAP/EJBs/etc. then I recommend looking at Apache Camel. Camel is an integration service that can integrate with pretty much every service or protocol out there. And, I believe, it supports rudimentary transactions. You can make a single service call and Camel will handle the routing and integration with whatever backend services you define. And, you can chain them. So, your flow would look like this:
Client makes call to service 'FOO'...
'FOO' is defined as a route that makes a REST call to '/bar', followed by an EJB call to 'MyService', followed by persisting the results to a SQL database, and then lastly calling a SOAP web service. The client then gets back the return value from this call, which can be whatever transformation or permutation of these calls you want. It's completely transparent to the client where the result came from.
I have been working in a Government Project using EJBs. I have found some Server issues while deploying EJBs. People working in my project have thought about removing EJBs from between the RequestHandler & DAO and to directly call DAO methods from RequestHandler.
My argument with this matter is, how can we even think about removing EJBs from the project which itself has the base framework as EJB !!!
Please inform about the correct solution required to improve performance while deployment & also inform the other way to improve speed & performance.
I have worked on a few projects where removing EJB improved performance dramatically.
For me using EJBs is about improving productivity and the quality of the solution you produce rather than worrying about performance. Usually performance isn't a big issue, but if it is you can throw hardware at it and use a cloud/distributed solution, which costs less than it used to. i.e. it can be cheaper than spending more time developing.
Check whether you are doing remote EJB calls or local EJB calls.
Doing remote calls within a project might lead to performance issues (if you are logically working locally).
it's impossible to answer the question with no information provided. however, if you don't use the ejb services for anything you may as well get rid of them. it's not unlikely the reason to call your dao via ejb in the first place was to utilize CMT, so if you ditch ejb you need to handle transactions by other means.
in general, my advice is to try to figure out what the question/problem really is before you start looking for answers.
Depends on what EJBs you are talking about.
Session Beans : Having them or not will have barely any impact on performance.
Entity Beans : Entity beans can have a drastic effect on performance. I would use them in a situation where you are dealing with complex transactions in create, delete or update calls (CRUD). In situations where I am just calling a query (CRUD) which returns 1000s of records I might switch to pure JDBC.
A lot of JPA/EJB containers these days are pretty smart, so maybe they can delegate performance issues to the database level.
For example: If I return 10000 customer objects, and each customer has multiple addresses, I could join the customer and address objects in the EJB layer. This may be as fast as creating a join in the database level and returning data as a view if the EJB container is smart enough.
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
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.
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 distributed is 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.
So, this is very late answer for this but finally I'm ready to answer. I'll put some details here about further developing of the REST service application.
Finally I landed on solution #1 from tolitius's great answer with option to migrate to solution #2 on later stage.
This is the application architecture - I'll add graphics later.
Persistence layer - this holds domain model, all database operations. Generated from database model with Spring Roo, generated repository and service layer for easy migration later.
Business layer - here is located all the business logic necessary for the oprations. This layer depends on Persistence layer.
Presentation layer validation, controllers calling Business layer.
All of this is run on Tomcat without Application server extras. On later phase this can be moved to Application server and implement Service locator pattern fully.
Infrastructure - geo located servers with geo load balancer, MySQL replication ring between all of them and one backup server and one backup server in case of fail.
My idea was to make more modern system architecture but from my experience with Java technology this is a "normal risk" situation.
With more experience - more beautiful solutions :) Looking forward for this!
I'm building a spring application for the first time. I'm running into lots of problems with concurrency, and I suspect that there is something wrong with the way I'm managing the backend. The only difference I can see between my backend code and examples I've seen are manager classes.
In my code, I have my model (managed by hibernate) and my DAOs on top of that to do CRUD/searching/etc on the models. In example code I have looked at, they never use the DAO directly. Instead, they use manager classes that call the DAOs indirectly. To me, this just seems like pointless code duplication.
What are these manager classes for? I've read that they wrap my code in "transactions," but why would I want that?
Transactions are used to make updates "transactional".
Example) A user clicks a webpage that leads to 13 records being updated in the database. A transaction would ensure either 0 or 13 of the updates go through, an error would make it all roll back.
Managers have to do with making things easier to do. They will not magically make your code threadsafe. Using a DAO directly is not a thread safety bug in and of itself.
However, I suggest you limit the logic in your DAO, and put as much logic as you can in the business layers. See Best practice for DAO pattern?
If you post maybe a small example of your code that isn't working well with multiple threads, we can suggest some ideas... but neither transactions nor managers alone will fix your problem.
Many applications have non trivial requirements and the business logic often involves access to several resources (e.g. several DAOs), coordination of these accesses and control of transaction across these accesses (if you access DAO1 and DAO2, you want to commit or rollback the changes as an indivisible unit of work).
It is thus typical to encapsulate and hide this complexity in dedicated services components exposing business behavior in a coarse-grained manner to the clients.
And this is precisely what the managers you are referring to are doing, they constitute the Service Layer.
A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.
DAOs should not own transactions, because they have no way of knowing whether or not they're only a part of a larger transaction.
The service tier is where transactions belong. You're incorrect to say they're a "pointless code duplication."
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is there a viable alternative to Hibernate? Preferably something that doesn't base itself on JPA.
Our problem is that we are building a complex (as in, many objects refer to each other) stateful RIA system. It seems as Hibernate is designed to be used mainly on one-off applications - JSF and the like.
The problem is mainly that of lazy loading. Since there can be several HTTP requests between the initialization and actually loading lazy collections, a session per transaction is out of the question. A long-lived session (one per application) doesn't work well either, because once a transaction hits a snag and throws an exception, the whole session is invalidated, thus the lazy loaded objects break. Then there's all kinds of stuff that just don't work for us (like implicit data persisting of data from outside an initialized transaction).
My poor explanations aside, the bottom line is that Hibernate does magic we don't like. It seems like TopLink isn't any better, it also being written on top of EJB.
So, a stateless persistence layer (or even bright-enough object-oriented database abstraction layer) is what we would need the most.
Any thoughts, or am I asking for something that doesn't exist?
Edit: I'm sorry for my ambiguous terminology, and thank you all for your corrections and insightful answers. Those who corrected me, you are all correct, I meant JPA, not EJB.
If you're after another JPA provider (Hibernate is one of these) then take a look at EclipseLink. It's far more fully-featured than the JPA 1.0 reference implementation of TopLink Essentials. In fact, EclipseLink will be the JPA 2.0 reference implementation shipped with Glassfish V3 Final.
JPA is good because you can use it both inside and outside a container. I've written Swing clients that use JPA to good effect. It doesn't have the same stigma and XML baggage that EJB 2.0/2.1 came with.
If you're after an even lighter weight solution then look no further than ibatis, which I consider to be my persistence technology of choice for the Java platform. It's lightweight, relies on SQL (it's amazing how much time ORM users spend trying to make their ORM produce good SQL) and does 90-95% of what JPA does (including lazy loading of related entities if you want).
Just to correct a couple of points:
JPA is the peristence layer of EJB, not built on EJB;
Any decent JPA provider has a whole lot of caching going on and it can be hard to figure it all out (this would be a good example of "Why is Simplicity So Complex?"). Unless you're doing something you haven't indicatd, exceptions shouldn't be an issue for your managed objects. Runtime exceptions typically rollback transactions (if you use Spring's transaction management and who doesn't do that?). The provider will maintain cached copies of loaded or persisted objects. This can be problematic if you want to update outside of the entity manager (requiring an explicit cache flush or use of EntityManager.refresh()).
As mentioned, JPA <> EJB, they're not even related. EJB 3 happens to leverage JPA, but that's about it. We have a bunch of stuff using JPA that doesn't even come close to running EJB.
Your problem is not the technology, it's your design.
Or, I should say, your design is not an easy fit on pretty much ANY modern framework.
Specifically, you're trying to keep transactions alive over several HTTP requests.
Naturally, most every common idiom is that each request is in itself one or more transactions, rather than each request being a portion of a larger transaction.
There is also obvious confusion when you used the term "stateless" and "transaction" in the same discussion, as transactions are inherently stateful.
Your big issue is simply managing your transactions manually.
If you transaction is occurring over several HTTP requests, AND those HTTP requests happen to be running "very quicky", right after one another, then you shouldn't really be having any real problem, save that you WILL have to ensure that your HTTP requests are using the same DB connection in order to leverage the Databases transaction facility.
That is, in simple terms, you get a connection to the DB, stuff it in the session, and make sure that for the duration of the transaction, all of your HTTP requests go through not only that same session, but in such a way that the actual Connection is still valid. Specifically, I don't believe there is an off the shelf JDBC connection that will actually survive failover or load balancing from one machine to another.
So, simply, if you want to use DB transactions, you need to ensure that your using the same DB Connection.
Now, if your long running transaction has "user interactions" within it, i.e. you start the DB transaction and wait for the user to "do something", then, quite simply, that design is all wrong. You DO NOT want to do that, as long lived transactions, especially in interactive environments, are just simply Bad. Like "Crossing The Streams" Bad. Don't do it. Batch transactions are different, but interactive long lived transactions are Bad.
You want to keep your interactive transactions as short lived as practical.
Now, if you can NOT ensure you will be able to use the same DB connection for your transaction, then, congratulations, you get to implement your own transactions. That means you get to design your system and data flows as if you have no transactional capability on the back end.
That essentially means that you will need to come up with your own mechanism to "commit" your data.
A good way to do this would be where you build up your data incrementally into a single "transaction" document, then feed that document to a "save" routine that does much of the real work. Like, you could store a row in the database, and flag it as "unsaved". You do that with all of your rows, and finally call a routine that runs through all of the data you just stored, and marks it all as "saved" in a single transaction mini-batch process.
Meanwhile, all of your other SQL "ignores" data that is not "saved". Throw in some time stamps and have a reaper process scavenging (if you really want to bother -- it may well be actually cheaper to just leave dead rows in the DB, depends on volume), these dead "unsaved" rows, as these are "uncomitted" transactions.
It's not as bad as it sounds. If you truly want a stateless environment, which is what it sounds like to me, then you'll need to do something like this.
Mind, in all of this the persistence tech really has nothing to do with it. The problem is how you use your transactions, rather than the tech so much.
I think you should have a look at apache cayenne which is a very good alternative to "big" frameworks. With its decent modeler, the learning curve is shorten by a good documentation.
I've looked at SimpleORM last year, and was very impressed by its lightweight no-magic design. Now there seems to be a version 3, but I don't have any experience with that one.
Ebean ORM (http://www.avaje.org)
It is a simpler more intuitive ORM to use.
Uses JPA Annotations for Mapping (#Entity, #OneToMany etc)
Sessionless API - No Hibernate Session or JPA Entity Manager
Lazy loading just works
Partial Object support for greater performance
Automatic Query tuning via "Autofetch"
Spring Integration
Large Query Support
Great support for Batch processing
Background fetching
DDL Generation
You can use raw SQL if you like (as good as Ibatis)
LGPL licence
Rob.
BEA Kodo (formerlly Solarmetric Kodo) is another alternative. It supports JPA, JDO, and EJ3. It is highly configurable and can support agressive pre-fetching, detaching/attaching of objects, etc.
Though, from what you've described, Toplink should be able to handle your problems. Mostly, it sounds like you need to be able to attach/detach objects from the persistence layer as requests start and end.
Just for reference, why the OP's design is his biggest problem: spanning transactions across multiple user requests means you can have as many open transactions at a given time as there are users connected to your app - a transaction keeps the connection busy until it is committed/rolled back. With thousand of simultaneously connected users, this can potentially mean thousands of connections. Most databases don't support this.
Neither Hibernate nor Toplink (EclipseLink) is based on EJB, they are both POJO persistancy frameworks (ORM).
I agree with the previous answer: iBatis is a good alternative to ORM frameworks: full control over sql, with a good caching mechanism.
One other option is Torque, I am not saying it is better than any of the options mentioned above but just that it is another option to look at.
It is getting quite old now but may fit some of your requirements.
Torque
When I was myself looking for a replacement to Hibernate I stumbled upon DataNucleus Access Platform, which is an Apache2-licensed ORM. It isn't just ORM as it provides persistence and retrieval of data also in other datasources than RDBMS, like LDAP, DB4O and XML. I don't have any usage experience, but it looks interesting.
Consider breaking your paradigm completely with something like tox. If you need Java classes you could load the XML result into JDOM.