I have an object which represents a databse entity cached in a session.But I require a mechanism where in the HTTPSession would change the object state automatically when the database entity state changes?
Why reinvent the wheel? What you are trying to do is implemented in various cache implementations out there in Sourceforge and other Open Source repositories - JCache implementation.
If you are building just for an entity alone and do not want to use such bulky ones - you need to have a thread that refreshes this automatically and keep outside of a session context. Because keeping cache of DB at session level would be so costly a design. Since I assume the DB entity is common for all users - why not cache it in a singleton than in session ! A session level DB cache would be disasterously costly for you.
Even when you do a singleton cache, make sure you do your math properly - for instance, if your thread is going to refresh the cache , say 100 times a day and your user access is going to be only less than 100 times per day to this entity, you are still killing in design - because it may be (note ; I said may be), better to access DB directly unless your goal is response time and not IO optmization.
we are using toplink generated objects, whose copy is stored in the session context.
Unfortunately none of us have enough expertise on toplink.I am sure toplink has some provision to do this but for time being we need to come up with some strategy.
I would try your suggestion in the meanwhile.
Toplink has its own robust caching framework. I would recommend not storing a copy of the DB entity object in the HTTPSession, but storing a reference to the object in the session. The the session attribute will refer to the object managed in the Toplink cache, and Toplink will manage whether or not it needs to be refreshed from the database.