On Feb 10, 2010, at 7:45 PM, Eelco Hillenius wrote: >> 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.
Definitely agree with the proxy approach (i.e. connection pools). I would proxy interfaces to implementations that can cache connections, check connections, open new connections, etc. -bp -- 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.
