Hi,
We have some data that is updated to a table from a web-page, the updates are correctly reflected in the database, but when the page is reloaded, some old values show up on the screen.

Interestingly there is a strange pattern, on clicking on the update button repeatedly without modifying the data the previous value(value before the first update) shows up every 5th time.
When the same is done with different data each time, the data shown up on the screen is one amongst the last 5 updates.

Presume this has something to do with the way the data is cached. But we have not done anything to enable caching.

The hibernate mappings are straight and simple with no mapping dependency to any other table.

The mapping-


The update code is as follows-


After update, the retrieve often shows up old values on screen.



We're passing a connection object fetched from a connection-pool to Hibernate. Both the update and the fetch happen within the same transaction.

Is there something fundamentally wrong with the code? Why could the old data show up on screen at regular intervals?

-Thanks in adv.

Sounds like it's not related to Hibernate

i think it is related to the way you manage the hibernate session.
This can occur if your servlet use a dirty session, to avoid this please search about "open session in view" in hibernate site.


Anthony

Our framework is thus-
Struts ->Action->EJB->Data Access
Can I still use the "open session in view" pattern?

We currently use the ThreadLocal pattern which checks for an open session object before fetching another. Isn't this sufficient? From what we saw in the "Open Session in View pattern" we figure the same is done there.

We're doing an intermediate session.flush(); once after the saveOrUpdate and once after the fetch, could this be a problem?

-Thanks

Ae you removing the session from the thread local at the end of the request? If not, you'll get an old session when the servlet container reuses that thread.

you need to
1- close
2- "remove" session from thread (on each request is the most secure)

We are closing the session and setting the ThreadLocal object to null at the end of the request.
In this particular case, the save and fetch are being done within the same request, so the session is not closed in between the save and fetch.

This is what we were doing-
I- For every transaction/request-
a) perform database operations( as described in II below)
b) close connection
c) set the ThreadLocal object to null
d) close the session

II- For every database operation -
a) getSession
b) perform db operation
c) flush

Now, if we close the session after the save and open it again for the fetch, it works fine, but I wonder if this is the right way to do it.
If we close the session and set the ThreadLocal object to null after the save, wouldn't we end up committing the data to the database, but we don't want to be committing until the transaction/request is complete.


We rely on the EJB container for transaction management. The database connection is also received from the app-server's connection pool.