I am dealing with messages in a mailserver. These messages are known by a String, a unique identifier. Processing of a message is complicated by the fact that a message can have any number of recipients, some of whom may have local POP3 mailboxes, and the rest of whom may require connection to any number of remote domains.
When a message first arrives I construct a Message object and do preliminary processing, which includes persisting the fields in a database. After that a number of asynchronous processes may need to deal with the message, when connection to one of the addressed domains is established, or when someone accesses the message is his POP3 mailbox. But the time between these accesses could be weeks, and the number of messages might grow large. So I suppose it best allow garbage collection of the Message object after a given operation is completed and the database updated, and then to construct a new Message object from the fields stored in the database when the next demand arises.
But, if one Message object for a given message is already in the JVM, I do not want to construct a second object if a second demand for that message comes up before the first is garbage collected. I'd like to have at most one Message object in the JVM for any given message (known by its String identifier).
For a while I thought I had a bright idea, to keep a store of Messages in the JVM. The store would be a HashMap of Messages with the String message identifier as the key. The store would return a pointer to a live Message if it had one, otherwise it would construct the Message new from the database.
But, if I am thinking smarter now, using such a store would prevent my Message objects from ever being garbage collected. It would defeat its own purpose. So, is there some way I can keep, or reconstruct, references to Objects without preventing the garbage collection of those objects?
Thanks, Rich Hammer
_______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
