> This is actually applicable to Socket Producer/Consumers, Database > failovers, etc.., hence the post. My sense is that implementing > Providers for each heavy weight object is the way to go, using a > Callable in a separate thread to re-connect in the get() method. The > problem of re-establishing the dependency graph still exists, however, > as the ExceptionListener for the Connection will get tripped in its > own thread and then all those existing dependent instances (Context, > ConnectionFactory, Connection, MessageProducer|Consumers) will need to > be notified, somehow. Right? Or am I missing the eloquent part? :-)
Like with database failovers, I think it is a matter of abstracting the connections themselves, like I hope everyone who uses database connections gets them from a pool rather than keeping a reference to one for the life time of a (long lived) object. I don't think the dependency graph should have much to do with it, though you could use providers to implement the abstractions you need. I think the key is to set up things lazily so that you don't have to notify dependencies in the first place. Eelco -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
