I'm not sure if you are asking, if a row in the database is changed first, then how to also have the object that exists (in another) hashmap be updated to reflect that changed database row ?
Or do you mean that changing the object, when saving it to the database, and you would have a reference to the hashmap, how would you find the object that was changed to update it as well. ?
If it was the first case, where possibly some other thread, or other process that has its own reference to its own separate copy of a hashmap of objects (kind of like a cache?) then we would need to have some kind of messaging bus, or event listener mechanism, where
- everything that had a copy of a hashmap that could write to the database table, would be able to generate an onChange() event.
- everything that had a copy of a hashmap would subscribe to the event bus, to receive these onChange() events. (event listeners)
The event we would send might be a simple object that just has the information for what database table and its primary key that has been changed. The event listeners would then perform an operation to replace the item in the hashmap by invoking a database query to re-read the value in the database, on no value found, the entry would then be removed from the hashmap.
There are some good examples of caching mechanisms and protocols to do this, such as in ehcache project. But to create your own event system, the transport will depend on the system architecture and deployment you are using. Threads within the same Java VM could just subscribe to an event source, a kind of dispatcher that allows event listeners to register them selves as a list of event listeners. Event notification over a network can be achieved with every node connecting to to a TCP socket server, where events sent in are regenerated to every connected peer, but in performance and high node count situations this might be better done with a multicast or otherwise UDP broadcast mechanism.
Error: Keyboard not attached. Press F1 to continue.