No server that has sucessfully passed CTS 1.2 -- official certification
based on that suite of 6,000+ tests, not certification based on subjective
interpretation of adherence to the specs -- can make use of passing objects
by reference. This optimization is strictly disallowed, not a permissable
value-add. That's not to say it isn't valuable, and non-compliant servers do
have an advantage there. It's just to say that if you're using a certified
app server, don't expect this local optimization.
A future version of the spec will address this.
psn
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Dan Christopherson
Sent: Friday, February 23, 2001 1:10 PM
To: [EMAIL PROTECTED]
Subject: Re: If the EJBs are on the local machine will it avoid making
rem ote calls?
On Fri, 23 Feb 2001, Thibault Cuvillier wrote:
> Dan,
>
> >Specifically, the EJB Container is not allowed to pass
> >non-remote objects
> >by reference on inter-EJB invocations when the calling and called
> >enterprise beans are collocated in the same JVM. Doing so
> >could result in
> >the multiple beans sharing the state of a Java object, which
> >would break
> >the enterprise beans semantics.
>
> Thank for the spec outline Dan.
>
> But, most of the AS do not duplicate the objects passed by reference by
> the middleware during a local call, which break the EJB semantic.
Then they're not spec-compliant.
>
> That's mean that when you develop an EJB, you must be aware about
> problem, and keep in mind that pass-by-value objects may be in fact passed
> by references in the case of a local call.
I'd say "should be aware" - most AS will allow you to turn on this
optimization, some may default to having it on, but if you can't coax the
container to do pass by value, it isn't an EJB 1.1 (or 2.0,
when there is such a thing) container.
>
> So the following code is dangerous:
> public void doSomeStuff(List list) {
> list.add("hello");
> // do some stuff with "list"
> }
> This code should be fixed as:
> public void doSomeStuff(List list) {
> List local = new ArrayList();
> Collections.copy(list, local);
> local.add("hello");
> // do some stuff with "local" }
>
> This example applied as well to by-values returned objects:
> private List accounts;
>
> public List getAccounts() {
> return accounts;
> }
> This client may change the account list if the case of a local
call
> (passed by reference), which break the encapsulation.
>
> This method should be fixed as:
> private List accounts;
>
> public List getAccounts() {
> List copy = new ArrayList();
> Collections.copy(accounts, copy);
> return copy;
> }
> Or (better solution)
> private List accounts;
>
> public List getAccounts() {
> return Collection.unmodifiableList(accounts);
> }
>
> Tibo.
>
>
===========================================================================
> 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".
>
--
Dan Christopherson (danch)
nVisia Technical Architect (www.nvisia.com)
Opinions expressed are mine and do not neccessarily reflect any
position or opinion of nVISIA.
---------------------------------------------------------------------------
If you're a capitalist and you have the best goods and they're
free, you don't have to proselytize, you just have to wait.
-Eben Moglen
===========================================================================
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".
