[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra JmsManagedConnection.java
User: pra Date: 01/09/22 07:00:42 Modified:src/main/org/jboss/jms/ra JmsManagedConnection.java Log: Fixed connection bug. Connection was never started and therefore sync receive did not work. Hereby fixed. Revision ChangesPath 1.7 +2 -2 jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java Index: JmsManagedConnection.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- JmsManagedConnection.java 2001/08/06 22:55:01 1.6 +++ JmsManagedConnection.java 2001/09/22 14:00:42 1.7 @@ -114,7 +114,7 @@ * * @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a. * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a - * @version $Revision: 1.6 $ + * @version $Revision: 1.7 $ */ public class JmsManagedConnection implements ManagedConnection @@ -621,7 +621,7 @@ logger.log(Level.FINE, xaQueueSession: + xaQueueSession); logger.log(Level.FINE, queueSession: + queueSession); } - + con.start(); logger.log(Level.FINE, transacted: + transacted); logger.log(Level.FINE, ack mode: + ack); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra JmsManagedConnection.java
User: pra Date: 01/09/22 08:51:39 Modified:src/main/org/jboss/jms/ra Tag: Branch_2_4 JmsManagedConnection.java Log: Backported connection start bug to 2.4 branch, now sync receive work Revision ChangesPath No revision No revision 1.1.4.3 +2 -2 jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java Index: JmsManagedConnection.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java,v retrieving revision 1.1.4.2 retrieving revision 1.1.4.3 diff -u -r1.1.4.2 -r1.1.4.3 --- JmsManagedConnection.java 2001/08/24 11:54:20 1.1.4.2 +++ JmsManagedConnection.java 2001/09/22 15:51:39 1.1.4.3 @@ -114,7 +114,7 @@ * * @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a. * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a - * @version $Revision: 1.1.4.2 $ + * @version $Revision: 1.1.4.3 $ */ public class JmsManagedConnection implements ManagedConnection @@ -617,7 +617,7 @@ throw new ResourceException (Connection was not reconizable: + con); } - + con.start(); logger.log(Level.FINE, xaQueueSession: + xaQueueSession); logger.log(Level.FINE, queueSession: + queueSession); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra JmsManagedConnection.java
User: user57 Date: 01/07/20 19:11:12 Modified:src/main/org/jboss/jms/ra JmsManagedConnection.java Log: o Using ConnectionFactoryHelper to create connections. Now XA connections will be created if the factory is an XA factory. o Defaulting xaTransacted to false, since the only place that it is set is when creating an xa connection (so it was always true). o Documented some more stuff Revision ChangesPath 1.5 +363 -218 jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java Index: JmsManagedConnection.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- JmsManagedConnection.java 2001/07/11 00:20:04 1.4 +++ JmsManagedConnection.java 2001/07/21 02:11:12 1.5 @@ -46,6 +46,7 @@ import javax.resource.spi.IllegalStateException; import javax.resource.spi.ConnectionEvent; +import org.jboss.jms.ConnectionFactoryHelper; import org.jboss.jms.jndi.JMSProviderAdapter; /** @@ -67,97 +68,104 @@ *LocalTx - we get a normal session. The LocalTransaction will then work *against the normal session api. * - * An invokation of JMS MAY BE DONE in none transacted context. What do we do - * then? How much should we leave to the user??? + * pAn invokation of JMS MAY BE DONE in none transacted context. What do we + *do then? How much should we leave to the user??? * - * One possible solution is to use transactions any way, but under the hood. - * If not LocalTransaction or XA has been aquired by the container, we have - * to do the commit in send and publish. (CHECK is the container required to - * get a XA every time it uses a managed connection? No its is not, only at - * creation!) - * - * Does this mean that a session one time may be used in a transacted env, - * and another time in a not transacted. - * - * Maybe we could have this simple rule: - * - * If a user is going to use non trans: - * - * - mark that i ra deployment descr - * - Use a JmsProviderAdapter with non XA factorys - * - Mark session as non transacted (this defeats the purpose of specifying - * trans attrinbutes in deploy descr NOT GOOD - * - * From the JMS tutorial: - * When you create a session in an enterprise bean, the container ignores - * the arguments you specify, because it manages all transactional properties - * for enterprise beans. - * - * And further: - * You do not specify a message acknowledgment mode when you create a - * message-driven bean that uses container-managed transactions. The - * container handles acknowledgment automatically. - * - * On Session or Connection: - * - * From Tutorial: - * A JMS API resource is a JMS API connection or a JMS API session. But in - * the J2EE spec only connection is considered a resource. + * pOne possible solution is to use transactions any way, but under the hood. + *If not LocalTransaction or XA has been aquired by the container, we have + *to do the commit in send and publish. (CHECK is the container required + *to get a XA every time it uses a managed connection? No its is not, only + *at creation!) + * + * pDoes this mean that a session one time may be used in a transacted env, + *and another time in a not transacted. + * + * pMaybe we could have this simple rule: + * + * pIf a user is going to use non trans: + * ul + * limark that i ra deployment descr + * liUse a JmsProviderAdapter with non XA factorys + * liMark session as non transacted (this defeats the purpose of specifying + * litrans attrinbutes in deploy descr NOT GOOD + * /ul + * + * pFrom the JMS tutorial: + *When you create a session in an enterprise bean, the container ignores + *the arguments you specify, because it manages all transactional + *properties for enterprise beans. + * + * pAnd further: + *You do not specify a message acknowledgment mode when you create a + *message-driven bean that uses container-managed transactions. The + *container handles acknowledgment automatically. + * + * pOn Session or Connection: + * pFrom Tutorial: + *A JMS API resource is a JMS API connection or a JMS API session. But in + *the J2EE spec only connection is considered a resource. * - * Not resolved: connectionErrorOccurred: it is verry hard to know from the - * exceptions thrown if it is a connection error. Should we register an - * ExceptionListener and mark al handles as errounous? And then let them send - * the event and throw an exception? + * pNot resolved: connectionErrorOccurred: it is verry hard to know from the + *exceptions thrown if it is a connection error. Should we register an + *ExceptionListener and
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra JmsManagedConnection.java
User: user57 Date: 01/07/10 17:20:04 Modified:src/main/org/jboss/jms/ra JmsManagedConnection.java Log: o re-indent fixup javadoc header (no code change) Revision ChangesPath 1.4 +389 -388 jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java Index: JmsManagedConnection.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- JmsManagedConnection.java 2001/06/22 05:24:31 1.3 +++ JmsManagedConnection.java 2001/07/11 00:20:04 1.4 @@ -49,426 +49,427 @@ import org.jboss.jms.jndi.JMSProviderAdapter; /** -pManaged Connection, manages one or more JMS sessions. -/p - - - pEvery ManagedConnection will have a physical JMSConnection under the hood. This may leave out several session, as specifyed in 5.5.4 Multiple Connection Handles. Thread safe semantics is provided. - /p - pHm. If we are to follow the example in 6.11 this will not work. We would have to use the SAME session. This means we will have to guard against concurrent -access. We use a stack, and only allowes the handle at the top of the stack to do things. - /p - pAs to transactions we some fairly hairy alternatives to handle: - XA - we get an XA. We may now only do transaction through the XAResource, since a XASession MUST throw exceptions in commit etc. But since XA support implies LocatTransaction support, we will have to use the XAResource in the LocalTransaction class. - LocalTx - we get a normal session. The LocalTransaction will then work against the normal session api. - - An invokation of JMS MAY BE DONE in none transacted context. What do we do - then? How much should we leave to the user??? - - One possible solution is to use transactions any way, but under the hood. If not LocalTransaction or XA has been aquired by the container, we have to do - the commit in send and publish. (CHECK is the container required to get a XA - every time it uses a managed connection? No its is not, only at creation!) - - Does this mean that a session one time may be used in a transacted env, and - another time in a not transacted. - - Maybe we could have this simple rule: - - If a user is going to use non trans: - - - mark that i ra deployment descr - - Use a JmsProviderAdapter with non XA factorys - - Mark session as non transacted (this defeats the purpose of specifying trans attrinbutes in deploy descr NOT GOOD - - From the JMS tutorial: - When you create a session in an enterprise bean, the container ignores the arguments you specify, because it manages all transactional properties for enterprise beans. - - And further: - You do not specify a message acknowledgment mode when you create a message-driven bean that uses container-managed transactions. The container handles -acknowledgment automatically. - -On Session or Connection: - -From Tutorial: -A JMS API resource is a JMS API connection or a JMS API session. But in the -J2EE spec only connection is considered a resource. - - -Not resolved: connectionErrorOccurred: it is verry hard to know from the -exceptions thrown if it is a connection error. Should we register an -ExceptionListener and mark al handles as errounous? And then let them send the event and throw an exception? + * Managed Connection, manages one or more JMS sessions. + * + * pEvery ManagedConnection will have a physical JMSConnection under the + *hood. This may leave out several session, as specifyed in 5.5.4 Multiple + *Connection Handles. Thread safe semantics is provided. + * pHm. If we are to follow the example in 6.11 this will not work. We would + *have to use the SAME session. This means we will have to guard against + *concurrent access. We use a stack, and only allowes the handle at the + *top of the stack to do things. * + * pAs to transactions we some fairly hairy alternatives to handle: + *XA - we get an XA. We may now only do transaction through the + *XAResource, since a XASession MUST throw exceptions in commit etc. But + *since XA support implies LocatTransaction support, we will have to use + *the XAResource in the LocalTransaction class. + *LocalTx - we get a normal session. The LocalTransaction will then work + *against the normal session api. * + * An invokation of JMS MAY BE DONE in none transacted context. What do we do + * then? How much should we leave to the user??? + * + * One possible solution is to use transactions any way, but under the hood. + * If not LocalTransaction or XA has been aquired by the container, we have + * to do the commit in send and publish. (CHECK is the container required to + * get a XA every time it uses a managed connection? No its
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/ra JmsManagedConnection.java
User: chirino
Date: 01/06/21 22:24:32
Modified:src/main/org/jboss/jms/ra JmsManagedConnection.java
Log:
Updated JBoss with the latest JBossMQ which includes fixes for the
recent threading issues. I have alos updated the JMProviderLoader
so that the references to the connection factory locations can be
set via JMX. The jboss.jcml file was updated so that MDBs uese the
INVM IL for better performance.
Revision ChangesPath
1.3 +3 -3 jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java
Index: JmsManagedConnection.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/ra/JmsManagedConnection.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- JmsManagedConnection.java 2001/06/18 20:01:26 1.2
+++ JmsManagedConnection.java 2001/06/22 05:24:31 1.3
@@ -102,7 +102,7 @@
* Created: Tue Apr 10 13:09:45 2001
*
* @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
*/
public class JmsManagedConnection implements ManagedConnection{
@@ -396,7 +396,7 @@
// Get connectionFactory
TopicConnectionFactory topicFactory =
(TopicConnectionFactory)context.
- lookup(adapter.getTopicFactoryName());
+ lookup(adapter.getTopicFactoryRef());
// Set up connection
if(user != null)
@@ -415,7 +415,7 @@
// Get connectionFactory
QueueConnectionFactory queueFactory =
(QueueConnectionFactory)context.
- lookup(adapter.getQueueFactoryName());
+ lookup(adapter.getQueueFactoryRef());
// Queue connection
if (user != null)
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
