Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


    public void launchContainerRunnable(Runnable runnable) {

        if (runnable instanceof JMSTopicRemoteConnection) {

            // Ignore local listener thread creation

        } else {




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


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:



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




Create instance caching all the JMS objects including unthread safe kind. Extract from:,r=6213/eclipselink/trunk/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/coordination/jms/


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:,r=6213/eclipselink/trunk/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/sessions/coordination/jms/


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:


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-----
From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx] On Behalf Of christopher delahunt
Sent: Friday, January 29, 2010 4:20 PM
To: eclipselink-dev@xxxxxxxxxxx
Subject: [eclipselink-dev] 2.1 Design doc for JMS-MDB cache coordination


Design documentation can be found here:



Please provide feedback either by replying to this email or using the

Wiki discussion page.





eclipselink-dev mailing list


Back to the top