| RE: [eclipselink-dev] 2.1 Design doc for JMS-MDB cache coordination |
|
Our requirements can be summarized to: 1- No thread creation, to be EJB specification compliant 2- No reuse of JMS objects between threads, to be JMS
specification compliant 3- Extensibility of the classes involved, to be able add functionalities
or fix bugs without having to modify the official EclipseLink jar Point 1 seems to be already covered by https://bugs.eclipse.org/bugs/show_bug.cgi?id=214534 Extract: public void
launchContainerRunnable(Runnable runnable) { if (runnable
instanceof JMSTopicRemoteConnection) {
// Ignore local listener thread creation } else {
super.launchContainerRunnable(runnable); } Point 2 doesn't seems to be covered yet by the bug
description/comment, bug patch, or wiki design. What need to be well understood
is that BOTH subscriber and publisher must use the JMS objects in a
thread safety manner. In the case of subscriber, including via listener but not
exclusively (even outside J2EE container JMS specification still apply),
unthread-safe object should ideally be recreated for each message received, or
only one listener should be configured; hoping the underline JMS implementation
are well coded to handle NOT concurrent reuse of object between threads. That
make sense to receive only on subscribed message at the time, but publishing
should be handled concurrently; So in publishing code many JMS object cannot be
reuse between thread, so they should be created on the fly for each message
published. The underline JMS framework is expected to optimize these objects
creation. So here the relevant information: What is thread safe or not in
JMS specification, extract from http://www.mail-archive.com/ejb-interest@xxxxxxxxxxxx/msg24680.html: ThreadSafe: Connection,
ConnectionFactory, Destination Non-ThreadSafe: Session,
MessageConsumer, MessageProducer, MessageListener Please note that TopicPublisher
and TopicSubscriber are MessageProducer and MessageListener respectively. JMS specification can be
downloaded here: http://java.sun.com/products/jms/docs.html Extract: JMS could have required that
all its objects support concurrent use. Since support for concurrent access
typically adds some overhead and complexity, the JMS design restricts its
requirement for concurrent access to those objects that would naturally be shared
by a multithreaded client. The remainder are designed to be accessed by one
logical thread of control at a time. JMS defines some specific rules that
restrict the concurrent use of Sessions. Since they require more
knowledge of JMS specifics than we have presented at this point, they will be
described later. Here we will describe the rationale forimposing them. There are two reasons for
restricting concurrent access to Sessions. First, Sessions are the JMS entity
that supports transactions. It is very difficult to implement transactions that are
multithreaded. Second, Sessions support asynchronous message
consumption. It is important that JMS not require that client code used for
asynchronous message consumption be capable of handling multiple, concurrent
messages. In addition, if a Session has been set up with multiple, asynchronous
consumers, it is important that the client is not forced to handle the case where
these separate consumers are concurrently executing. These restrictions
make JMS easier to use for typical clients. More sophisticated clients can get
the concurrency they desire by using multiple sessions. Create instance caching all the
JMS objects including unthread safe kind. Extract from: http://fisheye2.atlassian.com/browse/~raw,r=6213/eclipselink/trunk/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/coordination/jms/JMSTopicRemoteConnection.java public class
JMSTopicRemoteConnection extends BroadcastRemoteConnection implements Runnable
{ protected
TopicConnection topicConnection; protected
Topic topic; protected
TopicSession topicSession; protected
TopicPublisher publisher; protected
TopicSubscriber subscriber; Create un threadsafe
JMSTopicRemoteConnection: http://fisheye2.atlassian.com/browse/~raw,r=6213/eclipselink/trunk/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/sessions/coordination/jms/JMSTopicTransportManager.java protected
JMSTopicRemoteConnection createConnection(boolean isLocalConnectionBeingCreated)
throws RemoteCommandManagerException {
Context remoteHostContext = null;
try {
remoteHostContext = getRemoteHostContext(getTopicHostUrl());
TopicConnectionFactory connectionFactory = getTopicConnectionFactory(remoteHostContext);
Topic topic = getTopic(remoteHostContext);
TopicConnection topicConnection = connectionFactory.createTopicConnection();
// external connection is a puiblisher; local connection is a subscriber
return new
JMSTopicRemoteConnection(rcm, topicConnection, topic,
isLocalConnectionBeingCreated); Point 3 is important because we already customize this
existing EclipseLink module and other user had also to go through hoops.
Extensible implementation will not use private method or instance variable, and
not hardcode concrete classes like discussed by bug 244209.
We could verify if the implementation is flexible enough to handle this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=254287 Also our extension is about supporting our implementation
of Bug 260258,
it involves injecting our own CommandProcessor to dispatch the
command to the right session. To be able to do that we had to cascade
customization to the class hardcoding the concrete class so we had also to extends
RemoteCommandManager. To avoid us to copy/paste some code in our
implementation of CommandProcessor, method processCommandFromRemoteConnection
of RemoteCommandManager should small methods and hardcode no concrete classes. -----Original Message----- Design documentation can be found here: http://wiki.eclipse.org/EclipseLink/Development/2.1/JMSCacheCoordinationUsingMDB
<http://wiki.eclipse.org/EclipseLink/Development/JPA_2.0/undelimited_identifiers> Please provide feedback either by replying to this email
or using the Wiki discussion page. Thanks, Chris _______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipselink-dev |