ClientDataSource's implementation of Referenceable

[Jeremy Boynes <jb...@apache.org>]

I was intrigued by the implementation of Referenceable in the client 
DataSource impl - it uses the address entries in the reference to store 
the properties of the connection.

I may be misunderstanding this but I thought address fields in a 
Reference were used to store multiple potential locations for that 
reference not properties of an individual one.

I would suggest instead that we use one StringRefAddr to store the 
address with the value being a URL with suitable parameters set (i.e. as 
used by the Driver).

Ultimately, this will allow us to have references that point to multiple 
addresses (e.g. in a federated server)

--
Jeremy

Re: ClientDataSource's implementation of Referenceable

[Kathey Marsden <km...@sbcglobal.net>]

Jeremy Boynes wrote:

>
> I would like to replace this with storing all the properties in a
> single RefAddr. This would ultimately allow us to store multiple
> addresses in the Reference which the object factory could use to
> create the actual DataSource instance.


Thanks for the explanation Jeremy.  Could you call out how this would
converge or diverge from embedded behaviour from the user perspective? 

In general this is the question that I'd probably be looking for answers
for with respect to client changes.  Ideally,  I'd love to see switching
from Embedded to Client be as simple as  changing your DataSource.  

In general, if you can call out how your proposed changes to client
would  converge or diverge from embedded behaviour,
we can probably move things through a lot faster without the need for a
major education effort. 

Thanks

Kathey

Re: ClientDataSource's implementation of Referenceable

[Jeremy Boynes <jb...@apache.org>]

Kathey Marsden wrote:
>>
>>Ultimately, this will allow us to have references that point to
>>multiple addresses (e.g. in a federated server)
>>
> 
> Just some questions. Not educated enough in this area to comment yet #:)
> Could you explain the federated scenario  in more detail and how the
> referenceable DataSource would come into play?  

Some JNDI implementations support Java objects directly, so when you 
bind them in the actual object is stored in the directory usually by 
Serialization.

However, others don't. Instead a Reference gets stored which typically 
contains the information needed to reconstruct the object. JNDI uses an 
ObjectFactory associated with the Reference to convert it into the 
acutal Object.

A Reference typically stores the address of the target as a RefAddr, 
often as a StringRefAddr containing a URL as that makes it easier to 
understand when managing the directory.

It can actually store multiple RefAddrs indicating multiple places where 
the named resource can be found.

We are currently storing individual properties from the DataSource as 
RefAddr's in the reference. This works but IMO is an abuse of the system.

I would like to replace this with storing all the properties in a single 
RefAddr. This would ultimately allow us to store multiple addresses in 
the Reference which the object factory could use to create the actual 
DataSource instance.

A simple case would be where is used two different protocols depending 
on whether the client and server were on the same machine (e.g. shared 
memory based vs. TCP/IP based). Others would be where we had a clustered 
configuration and the reference contained the list of possible nodes to 
try. And so forth ...

> Also my JS169 red flag
> went up when I saw "URL"  and "Driver".  I was wondering are there
> JSR169 implications in doing this?
> 

All I meant was that the String stored in the reference should be of the 
same format as the String passed to the Driver. That should not cause 
any issues for JSR169.

--
Jeremy

Re: ClientDataSource's implementation of Referenceable

[Kathey Marsden <km...@sbcglobal.net>]

Kathey Marsden wrote:

Oops typos and another question.

>>    
>>
>I am sorry that I cannot provide any insight on why the DataSource
>implementations  implement Rerferenceable
>
[insert ]
in this way

>, except to say that I think 
>it is good that you seem to be taking  a fresh look at it in terms of
>what  we need for Derby.
>
>  
>
>>I would suggest instead that we use one StringRefAddr to store the
>>address with the value being a URL with suitable parameters set (i.e.
>>as used by the Driver).
>>
>>Ultimately, this will allow us to have references that point to
>>multiple addresses (e.g. in a federated server)
>>
>>    
>>
>Just some questions. Not educated enough in this area to comment yet #:)
>Could you explain the federated scenario  in more detail and how the
>referenceable DataSource would come into play?  Also my JS169 red flag
>went up when I saw "URL"  and "Driver".  I was wondering are there
>JSR169 implications in doing this?
>
>  
>
How does this all relate to the embedded implementation of
Referenceable?  I ask because in general I would like to see the client
Driver merge as much as possible with the embedded behaviour.

Thanks again

Kathey

Re: ClientDataSource's implementation of Referenceable

[Kathey Marsden <km...@sbcglobal.net>]

Jeremy Boynes wrote:

> I was intrigued by the implementation of Referenceable in the client
> DataSource impl - it uses the address entries in the reference to
> store the properties of the connection.
>
> I may be misunderstanding this but I thought address fields in a
> Reference were used to store multiple potential locations for that
> reference not properties of an individual one.
>
I am sorry that I cannot provide any insight on why the DataSource
implementations  implement Rerferenceable, except to say that I think 
it is good that you seem to be taking  a fresh look at it in terms of
what  we need for Derby.

> I would suggest instead that we use one StringRefAddr to store the
> address with the value being a URL with suitable parameters set (i.e.
> as used by the Driver).
>
> Ultimately, this will allow us to have references that point to
> multiple addresses (e.g. in a federated server)
>
Just some questions. Not educated enough in this area to comment yet #:)
Could you explain the federated scenario  in more detail and how the
referenceable DataSource would come into play?  Also my JS169 red flag
went up when I saw "URL"  and "Driver".  I was wondering are there
JSR169 implications in doing this?

Thanks

Kathey