Since JmsSession nor JmsManagedConnection needs to be synchronized to call
the underlying TopicSession or QueueSession object, lets drop it and let the
impl descide if it needs to be sync'd.
What do ya think.
--jason
On Wed, 8 Aug 2001 [EMAIL PROTECTED] wrote:
> On 7 Aug, Jason Dillon wrote:
> > Do you know why JmsSession.recover() is syncrhonized?
> >
>
> Simple answer, I really do not know. I stole it from SpySession.java
> (and since I did not know why that was syncrhonized I did not dare to
> change that.
>
> //Peter
>
> > --jason
> >
> >
> > On Wed, 8 Aug 2001 [EMAIL PROTECTED] wrote:
> >
> >> On 7 Aug, Jason Dillon wrote:
> >> > I might not be closing the session property in some cases. On a related
> >> > note, there is an example from sun:
> >> >
> >> >
>http://java.sun.com/products/jms/tutorial/examples/client_ses_mdb/PublisherBean.java
> >> >
> >> > which calls close() on the connection in ejbRemove(), but the JMS RA will
> >> > throw an exception in this case. Is there any reason why close() should not
> >> > be called?
> >>
> >> That sees like a bug, but it is important to remember that whats
> >> actually is pooled is the the session, and that should be closed after
> >> each method invocation.
> >>
> >> //Peter
> >> >
> >> > --jason
> >> >
> >> >
> >> > On Tue, 7 Aug 2001 [EMAIL PROTECTED] wrote:
> >> >
> >> >> On 6 Aug, Jason Dillon wrote:
> >> >> > Where does a JMS RA managed connection get returned? I just ran into:
> >> >> >
> >> >> > JmsXA [RMI TCP Connection(12)-192.168.0.124] INFO - Pool
> >> >> > org.jboss.jms.ra.JmsManagedConnectionFactory-1 is full (10/10)!
> >> >> >
> >> >> > JmsXA [RMI TCP Connection(12)-192.168.0.124] INFO - Pool
> >> >> > org.jboss.jms.ra.JmsManagedConnectionFactory-1 [10/10/10] waiting for a
> >> >> > free object
> >> >> >
> >> >> > Which I have never seen before. I looked over the ra classes briefly but I
> >> >> > can't seem to find out where they are returned.
> >> >>
> >> >>
> >> >> You may follow it thusly:
> >> >>
> >> >> 1. a client hold on to a JmsSession (org.jboss.jms.ra)
> >> >> 2. Invokes close on it.
> >> >> 3. JmsSession uses the JmsManagedConnection to send a CONNECTION_CLOSED
> >> >> connection event.
> >> >> 4. JmsManagedConnection (in sendEvent) will send a CONNECTION_CLOSED to
> >> >> all its registered ConnectionEventListeners.
> >> >>
> >> >> 5. The JBoss pool manager will detect the CONNECTION_CLOSED and invoke
> >> >> cleanup on the ManagedConnection (MC) (and perhaps som TX stuff) and
> >> >> return it to the pool.
> >> >>
> >> >>
> >> >> (If the pool management want to destroy managed connections in the pool
> >> >> it may do so, by invoking destroy() in the MC. The JmsSession or the
> >> >> JmsMC may also throw a connection event exception, in wich case the pool
> >> >> should destroy the MC.
> >> >>
> >> >> I do not really know if this helps in you solving the problem.
> >> >>
> >> >> //Peter
> >> >>
> >> >> > After a while the
> >> >> > transaction timed out and now the process is hung waiting for a connection.
> >> >> >
> >> >> > On a separate yet related note should/can the container signal the thread
> >> >> > running in a transaction that it has timed out... or just leave it
> >> >> > potentially locked forever?
> >> >> >
> >> >> > --jason
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Jboss-development mailing list
> >> >> > [EMAIL PROTECTED]
> >> >> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >> >>
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Jboss-development mailing list
> >> > [EMAIL PROTECTED]
> >> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >>
> >>
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
