This is a design question, concrete code not submitted to protect my bottom.
When working with Hibernate the standard workflow is as follows:
Here's another reason that I just ran into: caching previous results when calling a stored procedure multiple times within same transaction. Simplified code as follows.
//Begin transaction
SessionFactory sf = HibernateSessionFactory.getFactory();
Session dbSession = sf.getCurrentSession();
dbSession.beginTransaction();
//First call to stored procedure
Query query = dbSession.getNamedQuery("RR_CUST_OPP_DATA");
query.setString("custName", "A");
List shipSummaryRows = query.list();
//Second call to stored procedure
Query query = dbSession.getNamedQuery("RR_CUST_OPP_DATA");
query.setString("custName", "B");
List shipSummaryRows = query.list();
//Commit both
dbSession.getTransaction().commit();
Without a clear() after the first call, the resultset rows of the first call are replicated into the resultset of the second call. I'm using Oracle 11gR2.
Key to replicating this bug is to make both calls within the same transaction. Since I'm using open session in view pattern, both calls automatically happen within the same transaction (as the original code calls the proc within a loop storing the results of each). Hence I call it a bug; else could be considered a feature but even then clear() is not called out in code samples stating it should be called. session.flush() did nothing. Mapping file as below. As a result I've added clear() to the end of all my procedure calls. Have not yet tested with my custom SQL calls. This is trivial stuff; surprised the bug exists.
{ call RR_DASHBOARD_REPORTS_PKG.RR_CUST_OPP_DATA(?, :custName) }