Java – a substitute for hibernate or TopLink?
Is there a viable alternative to hibernate? Things that are not based on JPA are preferred
Our problem is that we are building a complex (as many objects refer to each other) stateful RIA system It seems that hibernate is mainly used for one-time applications - JSF, etc
The main problem is delayed loading Since there may be multiple HTTP requests between initialization and actual loading of lazy collections, the session of each transaction is impossible A long-standing session (one for each application) can not work normally, because once the transaction encounters obstacles and throws exceptions, the whole session will fail, so the delayed loaded objects will be interrupted Then there are all kinds of things that don't work for us (such as hiding data and persisting data from outside the initialization transaction)
In addition to my poor explanation, the most important thing is that hibernate did magic we don't like It seems that TopLink is not better. It is also written on top of EJB
Therefore, stateless persistence layer (even bright enough object-oriented database abstraction layer) is what we need most
What do you think, or do I ask for something that doesn't exist?
Editor: I'm sorry for my vague terminology, and thank you for your correction and insightful answers Those who correct me, you are all right. I mean JPA, not EJB
Solution
As mentioned above, JPA < > EJB, they are not even related EJB 3 happens to take advantage of JPA, but that's it We have a lot of things using JPA that are not even close to running EJB
Your problem is not technology, but your design
Or, I should say, your design is not suitable for any modern framework
Specifically, you try to keep the transaction active through multiple HTTP requests
Of course, most common idioms are that each request is itself one or more transactions, rather than each request is part of a larger transaction
When you use the terms "stateless" and "transaction" in the same discussion, there is also obvious confusion, because transactions are stateful in nature
Your big problem is managing your transactions manually
If your transaction occurs on multiple HTTP requests and these HTTP requests happen to be running "very fast", you should not really encounter any practical problems unless you must ensure that your HTTP requests use the same database connection to take advantage of the database transaction tool
In other words, simply put, you can get a connection to the database, populate it into the session, and ensure that during the transaction duration, all your HTTP requests not only pass through the same session, but also the actual connection in this way is still valid Specifically, I don't believe in an off the shelf JDBC connection that can actually survive failover or load balancing from one machine to another
Therefore, simply put, if you want to use database transactions, you need to ensure that the same database connection is used
Now, if there is "user interaction" in your long-running transaction, that is, you start the database transaction and wait for the user to "do something", then, very simply, this design is wrong You don't want to do this because long-term trading, especially in an interactive environment, is simply bad It's as bad as crossing a stream Don't do that Batch transactions are different, but interactive long - term transactions are wrong
You want to keep the interactive transaction in a real transient state
Now, if you can't ensure that you can use the same database connection for your transaction, Congratulations, you can implement your own transaction This means that you can design systems and data flows as if the back end had no transaction processing capabilities
This actually means that you need to propose your own mechanism to "submit" your data
A good way to do this is to gradually build the data into a single "transaction" document, and then provide the document to the "save" routine that performs most of the actual work For example, you can store a row in the database and mark it as unsaved You can perform this operation on all rows, and finally invoke routines that run all the data you just stored, and mark them all as "save" in a single transaction small batch process.
Meanwhile, all other SQL "ignores" unsaved data Throw out some timestamps and have a harvester process clean up (if you really want to disturb - it may actually be easier to leave dead rows in the database, depending on the number), these dead "unsaved" rows, because these are "unregistered" transactions
It's not as bad as it sounds If you really want a stateless environment, which is the case for me, then you need to do something like this
Remember, in all of these, Persistence technology has nothing to do with it The question is how you use your trade, not technology