Hi Tibo,
What is the conclusion of this question? Is it really true, that if you
cache EJBHome objects, you must synchronize them? I thought
the ejb container handled that?
If multiple clients grab the same EJBHome object from JNDI and
all use it simulataneously, the container must be at work managing
thread saftey. Or, is it the case that each client gets its own stub,
which is what allows the thread saftey.
If you have an understanding of this, could you please explain this.
I've just completed a design where I was planning to cache EJBHomes
and now I'm not sure.
thanks very much.
Thibault Cuvillier wrote:
> Karl,
>
> My question was about the ***proxies***, not about the beans.
>
> I can summary the responses I received to this problem: "never suppose that
> a proxy of an EJBHome nor an EJBObject is multi-thread safe".
>
> So, if I want to share a proxy to an EJBObject (or EJBHome) from the Web
> container, I have to wrap it with an object which synchronize all of the
> remote methods, (Smart Synchronizer Proxy).
>
> Example:
>
> // Remote EJB interface
> public interface AccountHome extends EJBHome {
> public Account create(String owner) throws ...;
> }
>
> // Synchronized smart proxy
> public class AccountSynch implements AccountHome {
> private AccountHome delegate;
>
> public AccountHomeSynch(AccountHome a) { this.delegate = a);
>
> public AccountHome synchronized create(String owner) throws ... {
> return this.delegate.create(owner);
> }
> ...
> }
>
> // Singleton cache
> class Cache {
> private static AccountHome cachedRef;
> private Cache singleton = new Cache();
>
> Cache() { // I cut the exceptions handling
> AccountHome notMTSafeHome = lookup and narrow;
> cachedRef = new AccountSynch(notMTsafeHome);
> }
>
> public static AccountHome getAccountHome() {
> return cachedRef; // should better to use lazy loading....
> }
> }
>
> // Client code (Servlet or JSP)
> AccountHome home = Cache.getAccountHome();
> Account acc = home.findByPrimaryKey("tibo");
> acc.credit(1000000);
>
> Limitations:
> - Load balancing
> - TX context and security credentials are stored in the local thread.
>
> Other solutions:
> - cache the remote references per thread.
>
> Correct ?
>
> Tibo.
> > -----Original Message-----
> > From: Karl Roberts [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, July 24, 2000 12:41 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Is a Proxy is thread-safe?
> >
> >
> > Whilst Entity Beans may not be 100% thread safe( you can't use the
> > synchronized keyword) the spec does suggest (and it is the default
> > behavior)
> > that they should be Non Reentrant, Session Beans are always Non
> > reentrant.
> > If they are non reentrant then threading is not a problem.
> > If you allow an Entity been to be reentrant then you open it up to
> > multithreading... with no synchronized keyword allowed then you better
> > be
> > sure of what you are doing.
> >
> > Hope it helps
> >
> > Karl
> >
> > -----Original Message-----
> > From: Jorgen Thelin [mailto:[EMAIL PROTECTED]]
> > Sent: 22 July 2000 13:15
> > To: [EMAIL PROTECTED]
> > Subject: Re: Is a Proxy is thread-safe?
> >
> >
> > Thibault Cuvillier <[EMAIL PROTECTED]> writes:
> > >Hi,
> > >
> > >2 short questions:
> > >
> > >Is a proxy to an EJB instance is thread safe?
> >
> > It depends exactly how you define "thread safe"!
> >
> > The EJB architecture and specification says that an EJB *instance* can
> > only be used by one thread at one, so in that sense the answer is NO.
> >
> > There is a slight trick here, as there is not always a one-to-one
> > mapping between EJB *references* (proxies) and EJB *instances*.
> > As an example a stateless session bean reference may well use a
> > different instance on each call [depending on the exact
> > instance pooling
> > implementation and policy of the server, etc, etc], so the answer may
> > well be YES in that case, but is probably implementation-specific.
> >
> > The EJB spec does not (AFAIK) preclude an EJB reference being
> > created on
> > one thread and being passed to and used from another thread [provided
> > you do not get simultaneous use from multiple threads], so in
> > that sense
> > the answer is MAYBE, and probably YES.
> >
> > .... HOWEVER, all the "caller context" information (current
> > transaction,
> > current security credentials) is basically thread-based, so the second
> > thread may well not be making a call with exactly the same context
> > environment, so in that sense the answer is MAYBE, but probably NO.
> > [It can depend to some extent exactly how the server has been
> > implemented whether this is a problem or not.]
> >
> > Overall, I would *tend* to say EJB *references* (proxies) ARE
> > NOT thread
> > safe in the normal expected definition of such things - i.e.
> > don't write
> > programs relying on it.
> > Put another way, as a developer you do always have to aware
> > of threading
> > issues in the client tier, and be particularly conscious that you make
> > an EJB call from the right thread -- just as you have to with
> > Swing GUI
> > coding.
> >
> >
> > [Note, this is completely different from the question of whether an
> > actual bean instance (on the server-side) can create threads, but lets
> > not get into that discussion again!]
> >
> >
> > >Is a proxy to an EJB Home is thread safe ?
> >
> > Most probably YES, but it may well be implementation-specific in
> > reality.
> > Again, the "caller context" *may* play a part, and the underlying
> > middleware itself may not be able to cope with simultaneous
> > calls, but I
> > very much doubt this will be a problem with any proper middleware.
> >
> > So I would *tend* to say EJB Home references (proxies) *should* be
> > thread safe, but check with your server vendor for confirmation.
> >
> > I am not sure the spec is explicit about this matter though,
> > so whether
> > it is safe to rely on this situation for all servers is perhaps
> > debatable.
> > Surely the whole point of the EJB spec is to define an
> > architecture that
> > allows your programs to work identically on *any* EJB server, so if it
> > is not defined in the spec, it should really be regarded as server-
> > specific IMHO.
> > [No doubt someone will point us to the appropriate place in
> > the spec if
> > it *is* actually specified somewhere!]
> >
> > >
> > >I cannot find any information in the spec, and I read a lot of
> > different
> > >responses.
> > >Is it middleware dependant ?
> > >
> > >Any idea?
> > >Tibo.
> > >
> >
> >
> > Hope that helps, rather than just confusing the matter even more!
> >
> > - Jorgen
> >
> > ----------------------------------------------------------------------
> > | Orbware Ltd http://www.orbware.com/ |
> > | --- Enterprise technology for the "real world" --- |
> > | Try the OrCAS EJB server -- Completely free for development use. |
> > ----------------------------------------------------------------------
> >
> > ==============================================================
> > ==========
> > ===
> > 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".
>
> ===========================================================================
> 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".
