db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: ClientDataSource's implementation of Referenceable
Date Wed, 04 May 2005 19:06:42 GMT
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 

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.


View raw message