Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Can we Achieve Location transparency in accessing database?  RSS feed

 
vikasids sharma
Ranch Hand
Posts: 157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As we have location transparency in case of accessing EJBs ,they can be moved to any other location without affecting client code.
Can we have location transparency in accesing database from EJBs?
thanks
Vikas
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suppose we could if the JDBC driver supported such a feature. Of course, if you're only talking about "static" transparency, we already have that via the connection URL, right?
 
vikasids sharma
Ranch Hand
Posts: 157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
lasse
i could not get "static transparency"
We hardcode the machine location hosting database in websphere configuration section while creating datasource for our database right?
Now if we want to move database to another machine location .
Is that we have to configure machine location again in configuration section? If so it means location transparency has not come in picture.
Is there any means so that we dont provide location of database in configuration section of websphere?
Originally posted by Lasse Koskela:
I suppose we could if the JDBC driver supported such a feature. Of course, if you're only talking about "static" transparency, we already have that via the connection URL, right?
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by vikasids sharma:
lasse
i could not get "static transparency"
We hardcode the machine location hosting database in websphere configuration section while creating datasource for our database right?
Now if we want to move database to another machine location .
Is that we have to configure machine location again in configuration section? If so it means location transparency has not come in picture.
Is there any means so that we dont provide location of database in configuration section of websphere?


What I meant with "static transparency" is that the location is transparent to the application code but the location cannot be changed at runtime without the client noticing (exception -> refetch datasource). Actually, I don't know for sure whether application servers support this kind of hot-swapping of database locations. Just an educated guess.
I guess you could move the database location out of WebSphere configuration by
1) Creating the datasource programmatically (you'll need vendor-specific APIs, I suspect), or
2) Using a "JDBC proxy", a JDBC driver pointing to something like "jdbc:myjdbcproxy://myconfig", which then again passes the JDBC calls forward to the actual database (no, I can't think of any such product)
 
vikasids sharma
Ranch Hand
Posts: 157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks lasse
So we cannot have location transparency in accessing Database.
No doubt static transparency will remain there...
lasse can u give any idea abt how key values are stored in some directory services.
Is that they are stored with fully qualified package to distinguish between two keys(names of two home objects belongs to different applications)
Originally posted by Lasse Koskela:

I guess you could move the database location out of WebSphere configuration by
1) Creating the datasource programmatically (you'll need vendor-specific APIs, I suspect), or
2) Using a "JDBC proxy", a JDBC driver pointing to something like "jdbc:myjdbcproxy://myconfig", which then again passes the JDBC calls forward to the actual database (no, I can't think of any such product)
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Regarding naming in directory services such as JNDI, there's generally two ways of creating names in the first place: by the "user" and by the "computer".
The user can usually assign whatever names she feels comfortable with. Such as "jdbc/MyStorefrontDatabase". The computer generally uses some kind of namespacing and categorization rules in order to avoid name clashes, for example "<resource type>/<application name>_<class name>_<running number>".
 
vikasids sharma
Ranch Hand
Posts: 157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thatz ok
but i m asking abt storing home objects.
Actually there could be the same name for two home objects(same key)belonging to two different application.
What is the general criteria implemented by JNDI to distinguish between two home objects having same key while storing in JNDI?

Originally posted by Lasse Koskela:
Regarding naming in directory services such as JNDI, there's generally two ways of creating names in the first place: by the "user" and by the "computer".
The user can usually assign whatever names she feels comfortable with. Such as "jdbc/MyStorefrontDatabase". The computer generally uses some kind of namespacing and categorization rules in order to avoid name clashes, for example "<resource type>/<application name>_<class name>_<running number>".
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually there could be the same name for two home objects(same key)belonging to two different application.
No there couldn't. Unless the applications have separate JNDI trees. You can witness this by browsing the API for java.naming.Context:
 
vikasids sharma
Ranch Hand
Posts: 157
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks lasse
so i conclude by saying "We cannot have two same keys(names representing home objects ) when working with same directory service , no matter they belong to two diiferent applications"
right?
Originally posted by Lasse Koskela:
No there couldn't. Unless the applications have separate JNDI trees. You can witness this by browsing the API for java.naming.Context:
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Right.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!