equals() for MCF

[Jeremy Boynes <je...@boynes.com>]

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

Re: equals() for MCF

[David Jencks <da...@coredevelopers.net>]

On Friday, April 30, 2004, at 07:25 AM, Jeremy Boynes wrote:

> David Jencks wrote:
>
>> 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.
>
> I can see that for a CF given components typically get them from JNDI; 
> it seems odd to me that this is a requirement for an MCF given the 
> only thing that uses them direclty is the connection manager.

remember that the cf is serializable and contains a reference to the 
mcf, which it  uses in the cm allocateConnection call.
>
>> 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.
>
> I hope this isn't true - I would like to be able to set properties 
> such as connection timeout, statement cache size, maybe password 
> without redeploying.
>
> Now those don't identify the backend, but others like server name 
> probably do and I can think of use cases where those might need to be 
> changed (e.g. server name during some failover reconfig).

I think changing what you are connecting to should be a redeployment.  
What I'd like is that the redeployment does not result in down time, 
but I haven't figured out how to do this yet.

david
>
> --
> Jeremy
>

Re: equals() for MCF

[Jeremy Boynes <je...@coredevelopers.net>]

David Jencks wrote:

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

I can see that for a CF given components typically get them from JNDI; 
it seems odd to me that this is a requirement for an MCF given the only 
thing that uses them direclty is the connection manager.

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

I hope this isn't true - I would like to be able to set properties such 
as connection timeout, statement cache size, maybe password without 
redeploying.

Now those don't identify the backend, but others like server name 
probably do and I can think of use cases where those might need to be 
changed (e.g. server name during some failover reconfig).

--
Jeremy

Re: equals() for MCF

[David Jencks <da...@coredevelopers.net>]

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