Accessing a database through a connection object
Hello,
I've written a database connection object which my application should use to connect to its database. The problem I'm encountering is that I'm not sure how to have an instance of that object always existing and how to allow any class in my project to get a reference to that object when needed. Is it possible to instantiate a class as soon as my application is started on the server?
I have looked into JNDI, but I'm not sure how to register that class with JNDI. I would also prefer to be able to deploy this application onto any server without having to login as admin and adding some database settings to the server. However, if that method is recommended, please let me know briefly how I would go about doing that on Sun Java System Application Server 9.
I've read this:
http://java.sun.com/products/jndi/tutorial/objects/storing/reference.html
... and it seems like it might do what I need. There are a few things there that don't quite make sense to me, such as why I need a factory class.
Thank you in advance,
Pavel
[1087 byte] By [
Pavel_Ya] at [2007-10-3 4:34:18]
cotton.m,Not quite what I'm looking for; I already have a connection pooling object which I'd like to use.
Why don't you try to store that connection object in a session and whereever you want just get the connection object from that session. but i don't know how well i t works? try this...
> Why don't you try to store that connection object in
> a session and whereever you
> want just get the connection object from that
> session. but i don't know how well i t works? try
> this...
This would get the OP is all sorts of troubles... well, on the bright side, it's good for learning... :P
Do you just want this?
public class PavelConnection{
private final static PavelConnection pc;
static{
pc = new PavelConnection();
}
private PavelConnection(){
// or whatever your constructor is
}
public static synchronized PavelConnection getConnection(){
return pc;
}
}
This seems dangerous in so many ways though.
You need a way to get the connection pool to use your connection object. Thisis why you need to define a factory, so the connection pool knows how to instantiate your connection object.
ejpa at 2007-7-14 22:37:57 >
Hi,
Thank you for the replies.
Storing a static reference of the connection pool object is a good idea, I was thinking something along those lines. However, can I register it with JNDI or something to be able to access it from any other class within the project?
Thanks,
Pavel
Correction to my previous post:
What cotton.m suggested (the static reference to an object instance) would make it accessible to other classes, so that's great. Thanks!
The questions that remain:
1) Is it possible to instantiate a class as soon as my application is started on the server? The static reference method would result in the class being instantiated on the first call to it. If the instantiation process is massive and would take about 10 seconds (not really, but I'm curious), can I have it instantiated on the application start-up?
2) Can I use JNDI to reference this class? I'd like to be able to use the
Context_Instance.lookup("...") method to obtain a reference to the object. This, again, is for curiousity.
Thank you!
> Correction to my previous post:
>
> What cotton.m suggested (the static reference to an
> object instance) would make it accessible to other
> classes, so that's great. Thanks!
I don't think this is good advice. I disagree with your requirement of not having to log in as admin and set up the JNDI data source. The container is going to do a much better job of managing connections than you ever will. The feature is available to you. My advice would be to use it. You'll only set that connection pool up once. The harm that you do to yourself by creating a custom connection class and trying to jump through all these hoops will remain as long as this app is in production.
There's no need to use a custom connection object unless you've written one to connect to a database where none is available. Use the drivers provided by the vendors. They know how to write them better than you do.
> The questions that remain:
>
> 1) Is it possible to instantiate a class as soon as
> my application is started on the server? The static
> reference method would result in the class being
> instantiated on the first call to it. If the
> instantiation process is massive and would take about
> 10 seconds (not really, but I'm curious), can I have
> it instantiated on the application start-up?
You can, but that's better handled by the app server.
> 2) Can I use JNDI to reference this class? I'd like
> to be able to use the
> Context_Instance.lookup("...") method to obtain a
> reference to the object. This, again, is for
> curiousity.
It's easy to do with the pool support from the container.
All these difficulties go away when you drop that requirement. I find that when something like this becomes very difficult to do, it's a sign that I might not be thinking about the problem correctly.
%
Thanks, duffymo.
I thought so as well, but wanted to know if there was a nice way to do it my way. The disadvantage of setting it up on the server is that all the developers would have to have it set up on their test servers also.
Could you briefly explain the process for setting up the database connectivity on the application server?
Can I still use my own connection pool object? I'm confident that it's close to as good as it gets, and I am using an official driver for the connections themselves.
Thank you.
Ah-ha! So really the problem is one of deployment.Is this also why you want to you use your own pool? I am still trying to understand that.
> Thanks, duffymo.
>
> I thought so as well, but wanted to know if there was
> a nice way to do it my way.
I think the struggles you're describing are telling you - there's no nice way. You're essentially duplicating all the code that the app server developers have already written for you.
> The disadvantage of
> setting it up on the server is that all the
> developers would have to have it set up on their test
> servers also.
Please explain why this is a disadvantage. Shouldn't every developer who's using an app server be knowledgable about administering it? Where I work, we're expected to know how to manage WebLogic.
> Could you briefly explain the process for setting up
> the database connectivity on the application server?
It's different with each app server, but you just have to supply a JNDI name and the usual suspects (e.g., driver class, database URL, username, password).
> Can I still use my own connection pool object? I'm
> confident that it's close to as good as it gets, and
> I am using an official driver for the connections
> themselves.
My philosophy is that if there's a good object available I use it. I don't want to have to write, test, and maintain any more than I have to. I'd use the connection pool object that was provided with my app server. If there isn't one provided, I'd probably reach for something like Apache's DBCP library. It's written, tested, and maintained by somebody else.
%
> Can I still use my own connection pool object? I'm
> confident that it's close to as good as it gets,
What gives you this confidence? A complete suite of TestNG unit tests? A large user community? A small list of defects in your bug tracking database? Have you designed it with thread safety in mind? Have you load tested it to see how well it performs under stressful conditions?
Unless you have all those things, I'd say that your confidence isn't quantifiable. It's not healthy to be too wedded to your own code.
%
Take duffymo's advise and use an available connection pool. If the Singleton pattern is new to you, you'll find plently of pitfalls on the road to getting a connection pool working.
> Do you just want this?Since you use eager initialization you don't need the synchonized on the getConnection call.
Okay, I agree. Thank you :)
