The idea is Not to do a create() in each thread, but rather pre-create a
pool of session bean references and have the threads allocate from the pool.
A pool manager can pre-create a number of references and grow the pool up to
a max as needed.
-Chris.
> -----Original Message-----
> From: Curt Smith [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, March 27, 2000 11:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Concurrent access / Client threaded access to EJBs
>
>
>
> Frank Sauer wrote:
>
> > 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.
>
> There's issues here for large scale systems who need more performance
> container
>
> memory efficiency than serializing calls to a pool of non-reentrant beans
> can
> provide?
>
> If your Entity is designed for re-entrant calls then why not?
>
> BTW, how does WLS 5.x propose to provide capacity when they've disallowed
> reentrant calls to Enties and SB's???
>
> Another typical scenario that needs higher perf. solution:
>
> Threaded client (500 threads) needs a handle to a SB that supports
> reentrant
> calls
> to a shared EJBObject. What else? Each thread does home.create() 500
> times???
>
>
>
> curt
>
> << File: Card for Curt Smith >>
===========================================================================
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".
