A very common use case for my application involves interacting with the same objects in several request-response cycles. I need to get an object from the repository, make changes to it, and several request-response cycles flush the object to the database. Possible changes include:
- Changing properties to any of the beans of the graph
- Adding objects (entities) to the graph as items of a collection (via root.getChildren().add(newChildren))
- Updating objects from the graph (either as items of a collection (via root.getChildren().get(key)) or instance variables (accessed via getXXX() methods)
- Adding objects (entities) to the graph as collaborators (for example: bean.setSomething(otherBean))
- Removing objects (entities) from collections
I have a working mapping. My problems are related to session management. Currently I open and close a session for each request-response cycle and never flush my objects till the end of the use case. This approach leads to dirty reads. Due to constraints of my model, the same entity can be used in several references, which I normally fill selecting an object from a db search. When I select an object which is already referenced in the graph, I get two different instances of the same guy (two objects with the same id). This leads to problems in the flushing stage.
I understand why this is happening, What I've been missing is something like a business transaction that can span several r-r cycles, with an identity map (which should solve the problem of repeated objects) and some sort of post db query evaluation which filters invalid objects (dirty reads), and possibly adds objects which are changed in the transaction that the db query hasnīt brought.
I read the documentation several times looking for something like this. Some of the problems could be solved using the new method saveOrUpdateCopy (this sounds similar to TopLink's mergeClone's semantics). I'm probably missing something. Have anybody needed something like this? Should I start writing this business transaction layer? Is Hibernate unsuitable for this? An additional constraint (but something I could do later) is the ability to run my application in a 3 tier configuration (several web servers running the crud forms and an application server that hosts the repository). I know this sounds like a place for EJBs but I prefer to leave them out of the ecuation (this is a product that could be deployed in (kinda) small machines.
TIA, Martin Paoletta
------------------------------------------------------- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ _______________________________________________ hibernate-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hibernate-devel
