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".
