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.
