Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Thu, 29 Apr 2004 21:58:04 -0700
Subject: Re: equals() for MCF
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v553)
Cc: Geronimo-Dev <geronimo-dev@incubator.apache.org>
To: Jeremy Boynes <jeremy@boynes.com>
From: David Jencks <david@coredevelopers.net>
In-Reply-To: <4091D486.6010900@boynes.com>
Message-Id: <F6F34DA8-9A62-11D8-96B9-003065F4889C@coredevelopers.net>
Content-Transfer-Encoding: 7bit

I've spent quite a bit of time over the last few years wondering just 
what they were thinking of with this requirement.

I think the situation they are trying to cover is that if you serialize 
and serialize a managed connection factory, the result should be 
.equals to what you started with.  This is not necessary with Geronimo 
but seems to be what they are suggesting as far as looking up a 
connection factory in jndi.

The mutable properties problem is indeed a problem.  I've always 
figured that if I changed the values the new and old mcfs would not be 
equal.  I'd prefer it if the spec included a lifecycle so the mcf could 
object if you changed the properties, or some kind of "freeze" method.

However, the spec also kind of implies that all the properties are set 
during deployment and not changed thereafter, so I think it is pretty 
much a theoretical problem.

david jencks


On Thursday, April 29, 2004, at 09:22 PM, Jeremy Boynes wrote:

> I see where the J2CA spec says that equals() and hashCode() should the 
> properties that make the MCF "unique and specific", but I have a 
> couple of concerns:
>
> 1) I don't know what that is. For example, with Oracle you can
>    specify the instance using a URL or by setting properties (host,
>    server, port, ...), so two instances could be configured in
>    different ways, have different properties, but point to the same
>    EIS instance.
>
> 2) All the properties are mutable, which could change the values
>    used in comparison. Short of implementing a JavaBean change
>    notification and have the CM subscribe I don't see how this
>    can work.
>
> Seems to me that the safest way is to define these using identity on 
> the MCF, then no two MCFs will be the same and the app server will 
> need to treat them differently. This does preclude a couple of 
> optimizations (e.g. that the CM could map two different CF's to the 
> same MCF) but I don't think it stops it working.
>
> An alternative may be to have the MCF delegate to the EIS 
> implementation e.g. by calling equals on a delegate instance e.g. the 
> OracleDataSource from above. That way the driver gets to determine 
> what is equivalent.
>
> Any thoughts?
> Jeremy
>
> ( For acronym decoding see the J2CA spec. )
>