A transaction is associated with a Session and is usually instantiated by a call to Session.beginTransaction(). A single session might span multiple transactions since the notion of a session (a conversation between the application and the datastore) is of coarser granularity than the notion of a transaction. However, it is intended that there be at most one uncommitted Transaction associated with a particular Session at any time.
so now i dont need to declare throws InfrastructureException and/or HibernatException
Notice i never use:
and also use a overall Session, created at top of class: am i playing with fire? (my app is a standalone desktop for crud use - only one single user ever)
One pratcal advantage i get from this aproach is that i dont need anymore to worry about re-opening a session everytime i use one.
this other aproach (the correct one?):
forces me to pay very carefull atention to the existence of sessions in my code - see this example:
[ March 26, 2005: Message edited by: miguel lisboa ]
If the Session throws an exception, the transaction must be rolled back and the session discarded. The internal state of the Session might not be consistent with the database after the exception occurs. <hr></blockquote> do i get back to (moderate) try catch? my answer is yes, in view of the need of the roll back.
do you agree? [ March 26, 2005: Message edited by: miguel lisboa ]
Originally posted by miguel lisboa: do i get back to (moderate) try catch? my answer is yes, in view of the need of the roll back.
do you agree?
Yes, to be make your application robust in the face of failures, you should be doing this. Ninety-nine times out of a hundred, it won't matter. But problems do occur, even in a single-user desktop application.
Sessions are designed to be lightweight and quick to create, thus the use of the SessionFactory which maintains the configuration. You will be fine creating one for each transaction with your application.
However, you don't normally want your DAO managing the transactions or session. This should be left to the business logic. If you are going to change a user's email address, for example. You want to
begin a transaction
find and load the user
set the new email address
save the user
flush the session
commit the transaction
This is another place Spring helps out. It provides classes to maintain thread-bound sessions and transactions. When a session is needed, if the thread doesn't have one already, a new one is opened and bound to the thread.
This is important because the session maintains the unit of work to flush to the database. If you load it in one session and then save it in a different session, you'll have to use saveOrUpdateCopy() so it can reload the user to tell which objects and values have changed.
For managing the transactions, Spring provides EJB-like method-level transaction demarcation. Spring will begin and commit/rollback transactions based on each method's transaction property.
Also, I had a recommendation for your DAO class. First, what does the "dao" instance variable do? I don't see it being used -- though there is a setter.
Anyway, since all the methods are typed against Object instead of the domain object's interface, Convencao, you could create a base class that would supply 90% of the methods for all of your DAOs.
Pull the different pieces out of each DAO and make them constructor arguments: domain class and domain class's name. Then all the other methods you have can move to the base class.If you go with the method suggested in the Hibernate documentation, using a common base class will save you tons of cut-n-paste code. As well, if you need to change it in the future, it's all in one place.
Originally posted by miguel lisboa: BaseDao looks really great!
I made a quick search in hibenate docs but wanst unable to find the BaseDao reference you mentioned; can you pls tell me where i can find it?
Thanks! I wrote it using your ConvencaoDao as a starter for you. The BaseDao I wrote for my work is based off the same idea, but it uses Spring's HibernateTemplate and wouldn't be very helpful. The main concept, though, is very applicable: create a base class that will handle 90% of the work.
The only things each domain class DAO I have to write has are the constructor call to pass in the class and its name and any search methods specific to that object.
I'm full of tinier men! And a tiny ad:
a bit of art, as a gift, that will fit in a stocking