Lightweight dataase use in Servlets
Roedy Green
I'd think I would only need a couple of connections, one for handling
hit counters and one for caching image width/height info.
I wondered if this simple minded way of handling it is considered
proper.
Make the reference to the connection a static object.
On first access, open the connection in static init code.
Protect access to the connection with a synchronised lock.
Set up an on-shutdown hook to close the connection.
My database access is so simple I don't think locking the connection
would impair performance much.
--
Roedy Green Canadian Mind Products
http://mindprod.com
No flying machine will ever fly from New York to Paris.
~ Orville Wright (born: 1871-08-19 died: 1948-10-30 at age: 77) 1908 We see that same conservative pessimism in those crafting today�s computers and computer tools. They are overwhelmed by the details of producing even today�s solutions. You need young, over-confident people who don�t know too much to chart the course ahead. This is especially true of global warming where the current generation has entirely given up hope of a green planet and sustainable human survival.
Donkey Hottie
> I am about to do some trivial database accesses from Servlet tag code.
>
> I'd think I would only need a couple of connections, one for handling
> hit counters and one for caching image width/height info.
>
> I wondered if this simple minded way of handling it is considered
> proper.
>
> Make the reference to the connection a static object.
No. JDBC is not thread safe, don't do that. Use a connection pool,
preferably via your servers JNDI lookups.
>
> On first access, open the connection in static init code.
Do not bother with things like this, connection pool handles it.
>
> Protect access to the connection with a synchronised lock.
Come on.
>
> Set up an on-shutdown hook to close the connection.
MVC pattern, close the connection when not needed in the Java code. No
hooks needed.
>
>
> My database access is so simple I don't think locking the connection
> would impair performance much.
You start with simple, you end with an own Struts.
--
You plan things that you do not even attempt because of your extreme
caution.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Use a connection pool,
>preferably via your servers JNDI lookups.
I gather I don't need Hibernate to get a connection pool. What would
you recommend?
Arne Vajhøj
> On Sun, 18 Oct 2009 08:40:33 +0300, Donkey Hottie <don...@fred.pp.fi>
> wrote, quoted or indirectly quoted someone who said :
>> Use a connection pool,
>> preferably via your servers JNDI lookups.
>
> I gather I don't need Hibernate to get a connection pool. What would
> you recommend?
The one that you app server already has.
Arne
Arne Vajhøj
Arne Vajhøj
> I am about to do some trivial database accesses from Servlet tag code.
>
> I'd think I would only need a couple of connections, one for handling
> hit counters and one for caching image width/height info.
>
> I wondered if this simple minded way of handling it is considered
> proper.
>
> Make the reference to the connection a static object.
>
> On first access, open the connection in static init code.
>
> Protect access to the connection with a synchronised lock.
>
> Set up an on-shutdown hook to close the connection.
>
> My database access is so simple I don't think locking the connection
> would impair performance much.
What you describe should work. But the connection pool approach is
better.
It scales better. And it is the "real way" of doing it (real way = the
way that can be used by high volume apps) and when it does not cost you
anything to do it the "real way", then do it that way.
Arne
John B. Matthews
Arne Vajhøj <ar...@vajhoej.dk> wrote:
Excellent! _Vide_supra_:
<http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html>
Outside an application server, I've use this lightweight standalone JDBC
connection pool manager:
<http://www.source-code.biz/snippets/java/8.htm>
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Donkey Hottie
Indeed. Try to stay away from 3rd party jars. If JDBC is enough, build
on Tomcat. If you need JPA or EJB3, go with JBoss or GlassFish. JBoss
has Hibernate with it, while GlassFish has Oracle TopLink.
If you go with Hibernate, try to stick with JPA, do not use any
Hibernate specific features.
Playing with standards and avoiding extra jars makes your application
portable between any Application Servers; which is a good thing in my
opinion.
If you take MVC design, you need 3rd part jars for the implementation if
you go with Tomcat. It does not have even the standard JSF in it. Tomcat
would need maybe Apache MyFaces, while JBoss or GlassFish come with some
implementation already there.
--
Q: Why did Menachem Begin invade Lebanon?
A: To impress Jodie Foster.
Lew
>> If Tomcat see:
>>
>> <http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html>
John B. Matthews wrote:
> Outside an application server, I've use this lightweight standalone JDBC
> connection pool manager:
>
> <http://www.source-code.biz/snippets/java/8.htm>
<http://commons.apache.org/dbcp/>
which works, among other ways, in conjunction with Tomcat JNDI resources.
--
Lew
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>It scales better. And it is the "real way" of doing it (real way = the
>way that can be used by high volume apps) and when it does not cost you
>anything to do it the "real way", then do it that way.
Thank you. I have seen the growth of complexity and volumes so many
times before I need no convincing it is best plan for it.
All this advice needs compiling as a new Java glossary entry.
Roedy Green
<see_w...@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :
>
>All this advice needs compiling as a new Java glossary entry.
http://mindprod.com/jgloss/jdbcconnectionpooling.html
Arne Vajhøj
> In article <4adb1766$0$279$1472...@news.sunsite.dk>,
> Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> Arne Vajhøj wrote:
>>> Roedy Green wrote:
>>>> On Sun, 18 Oct 2009 08:40:33 +0300, Donkey Hottie <don...@fred.pp.fi>
>>>> wrote, quoted or indirectly quoted someone who said :
>>>>> Use a connection pool, preferably via your servers JNDI lookups.
>>>> I gather I don't need Hibernate to get a connection pool. What would
>>>> you recommend?
>>> The one that you app server already has.
>> If Tomcat see:
>>
>> http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html
>
> Excellent! _Vide_supra_:
>
> <http://tomcat.apache.org/tomcat-6.0-doc/jndi-resources-howto.html>
>
> Outside an application server, I've use this lightweight standalone JDBC
> connection pool manager:
>
> <http://www.source-code.biz/snippets/java/8.htm>
The jakarta connection pool is also available for SE apps.
It is not even that hard to use.
MySQL example:
Class.forName("com.mysql.jdbc.Driver");
GenericObjectPool cp = new GenericObjectPool(null);
DriverManagerConnectionFactory dmcf = new
DriverManagerConnectionFactory("jdbc:mysql://localhost/Test", "", "");
PoolableConnectionFactory pcf = new
PoolableConnectionFactory(dmcf, cp, null, null, false, true);
PoolingDataSource ds = new PoolingDataSource(cp);
Connection con = ds.getConnection();
Arne
Arne Vajhøj
It is what Tomcat uses behind the scene.
Arne
Arne Vajhøj
> 18.10.2009 16:24, Arne Vajh�j kirjoitti:
>> Roedy Green wrote:
>>> On Sun, 18 Oct 2009 08:40:33 +0300, Donkey Hottie <don...@fred.pp.fi>
>>> wrote, quoted or indirectly quoted someone who said :
>>>> Use a connection pool, preferably via your servers JNDI lookups.
>>>
>>> I gather I don't need Hibernate to get a connection pool. What would
>>> you recommend?
>>
>> The one that you app server already has.
>
> on Tomcat. If you need JPA or EJB3, go with JBoss or GlassFish. JBoss
> has Hibernate with it, while GlassFish has Oracle TopLink.
>
> If you go with Hibernate, try to stick with JPA, do not use any
> Hibernate specific features.
>
> Playing with standards and avoiding extra jars makes your application
> portable between any Application Servers; which is a good thing in my
> opinion.
>
> If you take MVC design, you need 3rd part jars for the implementation if
> you go with Tomcat. It does not have even the standard JSF in it. Tomcat
> would need maybe Apache MyFaces, while JBoss or GlassFish come with some
> implementation already there.
It is not that difficult to put the JSF implementation you want in.
I would consider it a lot simpler than having to resolve the
issues that can arise when the app server comes with JSF implementation
X and you have a web app that comes with JSF implementation Y.
In general I agree with the point that it is easier if all the necesarry
stuff are already there.
Arne
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Class.forName("com.mysql.jdbc.Driver");
> GenericObjectPool cp = new GenericObjectPool(null);
> DriverManagerConnectionFactory dmcf = new
>DriverManagerConnectionFactory("jdbc:mysql://localhost/Test", "", "");
> PoolableConnectionFactory pcf = new
>PoolableConnectionFactory(dmcf, cp, null, null, false, true);
> PoolingDataSource ds = new PoolingDataSource(cp);
> Connection con = ds.getConnection();
>
>Arne
You create pcf then do nothing with it. Is that intentional?
Which of this code if any can you do in a static init?
--
Roedy Green Canadian Mind Products
http://mindprod.com
Nothing is so good as it seems beforehand.
~ George Eliot (born: 1819-11-22 died: 1880-12-22 at age: 61) (Mary Ann Evans)
Arne Vajhøj
> On Mon, 19 Oct 2009 08:54:54 -0400, Arne Vajh�j <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> Class.forName("com.mysql.jdbc.Driver");
>> GenericObjectPool cp = new GenericObjectPool(null);
>> DriverManagerConnectionFactory dmcf = new
>> DriverManagerConnectionFactory("jdbc:mysql://localhost/Test", "", "");
>> PoolableConnectionFactory pcf = new
>> PoolableConnectionFactory(dmcf, cp, null, null, false, true);
>> PoolingDataSource ds = new PoolingDataSource(cp);
>> Connection con = ds.getConnection();
>
That is how the examples I copied did it.
My guess is that the constructor does more than just constructing
an object.
> Which of this code if any can you do in a static init?
Assuming that we talk servlets, then I will still recommend
that you define the data source in the server config and get
a data source via JNDI.
If you insist on doing it yourself then get and save the data source
in init and use that whenever you need a connection.
Arne