i saw that from glassfish you can configure jdbc resources and jdbc connection pools, and i suppose that after that you can use these to connect to database. What will be the advantage of this setup over the conventional setup with connection parameters defined in hibernate.xml and using a driverManaged connection? Also, if i use this type o db connection do i still have to use c3p0 for connection pooling ?
ps. it seems that in EE it`s recommended to use this container managed approach and in java SE the other one.
i think the container managed database connection pool is preferred, because it abstracts the connection details from the application.
Consider the use case where if we had a properties file or xml file inside our web application .war file to define the connection to the database. when we deploy the .war file to a given target environment (dev, QA, production), we need to have our build script generate slightly different .war files, containing the required .properties file to define how it should hook up to its specific database.
and some other brainstorming ideas why container is better.
- if we ever wanted to promote a .war file from QA-> production, we can't, without having to modify the .war file or build a new .war file.
- if for some reason the hosting infrastructure changes or requires maintenance such that the database is now located at a new location, the application would require to be redeployed if the configuration was inside the .war file.
- perhaps for security, it is desired the application developers do not know the production database user/passwords, the .war file is dropped into the box by a system application administrator after they receive it from the developer.
- if more than one application should require the same database, they can efficiently share the same conainer managed connection pool, instead of each of them having to boot up a pool of their own.
- the pool connection logic, and jdbc drivers don't have to be contained in your .war file, they can be contained in the application server class path, and upgraded easily (separately) from the applications.
Hi Travishein and thanks for quick reply.
I already have some problems when i move the app from test environment to production, due the fact that i have to rebuild it, and this seems to be a good idea.
sorry for the stupid question that i'm about to ask, but i want to make sure that i fully understand the problem :)
if i use container managed pool i do not need c3p0 as connection pool manager, right ?
right, most containers like tomcat and glassfish come with some implementation of a JDBC connection pool, tomcat usually has one based on commons-dbcp.
So you would not need to have the database jdbc jar file or the connection pool (c3p0) jar file in your application.