In my application, I am storing a small table containing 50 records in a singleton class because the data in this table hardly changes - e.g. the list of countries.
Although, the concept is not good, I have to continue with it right now. Is there any solution in Hibernate which observe change in the table and on change, invoke a method of a class to update the variable.
Implement Ah no, you want to do it from the other side on. No, it's not possible. Best what you can do is to reload the data at certain intervals, for example once every hour. You can use Interceptor#onFlushDirty().java.util.TimerTask for this.
That said, a Singleton is really a bad idea. Just have it as some kind of an attribute of the main context. If it is for example an Java EE webapplication, you can use ServletContext for this.
Hibernate won't get notified of changes made at the table level. The (bad) solution would be to update the data through Hibernate's API and to use one of the callback provided by an Interceptor to do some black magic voodoo with the Singleton. But honestly, the (right) way to handle this would be to get rid of that singleton and to put the data in 2nd level cache (and to invalidate the cache if you update the table manually).
(EDIT: As ChssPly76 mentioned in a comment, there is an intermediary solution if removing the singleton is not an option which consists in modifying the singleton to find and return cached hibernate-managed entities like your countries for example.)
It seems that easiest approach to this is a trigger on the database end instead inside of your application. But this depends of course on the underlying database and if you really want to use SQL if everything else is done by Hibernate.
Your situation sounds ideal for the L2 cache since your objects rarely change and set your expulsion policy accordingly to refresh. Further if ALL mods are done through Hibernate then you can keep track of what happens through the events/interceptor infrastructure. Of course, any auxiliary tables Hibernate does not know about would have to be tracked by other means like how @BalusC suggested.
Everybody keeps repeating the chant about Singletons being evil, but this mainly goes for old fashioned (private constructor + getInstance method) Singleton implementations, their main drawbacks being hard to unit test and not robust in multi-threaded or clustered environments. However, Spring offers a perfectly valid possibility for 'singleton' beans within its context. Just because there are issues with some (very mainstream and heard to root out) implementations does not mean the Singleton pattern is always bad.