[Dan]

I hope I can word this question properly..this is probably a better question posted directly to the hibernate/spring forums.but..here goes…

I’m using Eclipse to generate my DAO objects against Hibernate:

I have 2 DAO’s tables/daos, etc we can for this use question..

The Account Table:
AccountID

The AddressTable:
addressID
AccountID

now my ‘service’ logic calls these methods:

Account acc = accountDAO.findById(id);      // works
Set s = acc.getAddresses();                          //works
Iterator i = s.iterator();                                     // works
i.next();        // blows up....

I believe this blows up in the iterator, becuase the account object returned by accountDAO.findById(id), is detached from the Hibernate session.
is this correct?
now I can of course rewrite the above logic so that it looks like:

session s = getSession();
Account a = (Account)s.load("com.bn.dao.Account", id);
Set s = a.getAddresses();
Iterator i = s.iterator();
i.next();   
s.close();

Is this whats intended? I would assume if we are generating DAOs that are intended to actually be useful..we would at least be able to provide the Session object to the DAO but I do not see a way to do this with the genreated dao? or am I missing something?

To double check: the DAOs are all generated with:

getHibernateTemplate().get(xxx); // this returns a detached instance correct? (i.e. it internallly must be creating/closing a session).

for all you out there, if you have entities dependencies like this what do you all do? just manage your session? or there another trick for using these generated DAOs. is there a way to for force HibernateTemplate to not use its own session internally?

[Dan]

After playing around with this some more..and poking around the net..here’s what I have come up with.

From what I can tell, if my service does:
TransactionStatus ts = transactoinManager.getTransaction(new DefaultTransactionDefinition());
Account acc = accountDAO.findById(id); // works
Set s = acc.getAddresses(); //works
Iterator i = s.iterator(); // works
i.next(); // works now!!
transactionManager.rollback();
Originally I thought one should only use transactions for writes..but I believe this is not true..as reads use ‘implicit’ transaction anyways. (while I’m not sure if the rollback call is needed here though i figure it can’t hurt and will likely free up some resources).
I still wonder the getTransaction() must ‘allocate’ a session for use..when is that session released? perhaps in the rollback/commit calls? (assuming its not a nested transaction I guess).

anyone know if this is in fact the way to be executing reads on these generated DOAs with object dependence?

[Author]

Posts