Is it possible to wrap the 'Connection' around some kind of 'ManagedConnection' that delegates to the actual Connection and restablishes the connection if it fails? That way client code doesn't have to concern itself with the internals of how connection may arbitrarily fail -- ManagedConnection will do it itself. The only thing that has access to a raw Connection is ManagedConnection, and everything else down the chain can pretend everything's fine.
Sam On Fri, Feb 12, 2010 at 6:51 PM, bklough <[email protected]> wrote: > Thanks, guys. Yes, good advice on the db connection pooling, but > that's a non-concern at this stage. > > (JNDI) > (JMS) > Context ------------> ConnectionFactory --------> Connection > > | > | > > V > V > Destination > Session > > | > | > +---------------> MessageProducer ------------+ > > | > | > +---------------> MessageConsumer ----------+ > > A dependency create walk might be: > > context = new > InitialContext(properties); // no > external connection at this point > connectionFactory = context.lookup("SomePrefinedName"); // JNDI > provider connection on default port 1099 > connection = connectionFactory.createConnection(...); // > socket pair opens to JMS provider via it's default port > session = connection.createSession(...); > destination = > context.lookup("TEST_TOPIC"); // JNDI > provider connection on default port 1099 > producer = session.createConsumer(destination); > consumer = session.createProducer(destination); > > I want to provide my clients with this: > > @Inject @Named("TEST_TOPIC") > MessageConsumer consumer; > > @Inject @Named("TEST_TOPIC") > MessageProducer producer; > > The problem is that errant connection drop. Reestablishing the > connection is easy, but, in this example, that leaves three > dependencies with valid references to stale instances: consumer, > producer, and session. Other implementations leave destination in the > wind. > > Is this simply a matter of having the Producer/Consumers re-establish > their dependencies via Provider .get() chains? Should the module > responsible for the initial wiring rewire or something? Or am I being > obtuse in not manditing the client code provide and listener method > responsible for recreating their Consumers/Producers themselves after > the library reestablishes the connections? > > -- > 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. > > -- 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.
