According to the EJB 1.1 spec the container is *supposed* to throw an exception on the 2nd-Nth re-entrant call. Apparently not all vendors are compliant yet. We ran into this problem (Gemstone is compliant and throws the exception) and solved it by creating a session pool on the client side. Frank Sauer The Technical Resource Connection Tampa, FL http://www.trcinc.com > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]]On Behalf Of Curt Smith > Sent: Monday, March 27, 2000 1:25 PM > To: [EMAIL PROTECTED] > Subject: Concurrent access / Client threaded access to EJBs > > > Hi, > > I'm trying to sort out a design that needs capacity and short > latency: > > I'm porting/converting a few corba services to EJBs: some entity > and some stateful session. > > The Spec is vague and vendor docs vary from vendor for the following > questions: > > Multple clients (multiple handles) concurrent access to same method: > > - Entity: when will the container allow concurrent calls into > same method > vs sequentially queue the calls? Or worse throw an > exception to the 2nd > -Nth calls. > > - Stateful Session: ditto > > - Session: at least one vendor allows a threaded client to > share the same > handle and allow concurrent calls in a session bean. Other > vendors throw > an exception on the 2nd-Nth calls... ;( > > -- > > Curt Smith > [EMAIL PROTECTED] > (w) 404-237-1166 x182 > > ============================================================== > ============= > To unsubscribe, send email to [EMAIL PROTECTED] and > include in the body > of the message "signoff EJB-INTEREST". For general help, > send email to > [EMAIL PROTECTED] and include in the body of the message "help". > > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
