31. januar 2009 - 17:00Der er
8 kommentarer og 1 løsning
Problemer med DB connection pool (tomcat / oracle)
Jeg arbejder paa et stoerre projekt og jeg har problemer med DB connections. Systemet kommer ikke til at have saerlig mange brugere paa samtidig, men det er ret connection tungt.
Maaden jeg har gjort det paa indtil videre er at lave en DB connection i Tomcat serveren... Altsaa dette i context.xml:
I java koden er alle mine metoder statiske og alle jsp sider starter med:
Connection con = SystemFunctions.getConnection();
Den metode ser saadan her ud:
public static Connection getConnection() {
Connection con = null; Context initContext = null; try { initContext = new InitialContext(); Context envContext = (Context)initContext.lookup("java:/comp/env"); DataSource ds = (DataSource)envContext.lookup("jdbc/xxxxx"); con = ds.getConnection(); } catch (NamingException e) { e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. } catch (SQLException e) { e.printStackTrace(); //To change body of catch statement use File | Settings | File Templates. } return con;
}
Naar jeg kalder metoder frem og tilbage fra jsp siderne sender jeg connection'en med, saaledes:
blogs = BlogFunctions.getLatestBlogs(con);
...og bruger saa den con(nection) i metoderne.
nederst paa alle jsp siderne lukker jeg con.
Jeg har haft nogle problemer paa sider med en del iframes som skulle bruge hver sin connection, saa jeg proevede at smide connectionen ned i session og hente den i iframes'ne saaledes:
Connection con = SystemFunctions.getConnection(); request.getSession().setAttribute("con", con);
--------
con = (Connection)request.getSession().getAttribute("con");
Alt dette virker saadan set. Men det haender ret ofte at systemet doer da con er closed eller connection er refused.
Tomcatten burde ellers haandtere denne pooled connection og naar jeg paa jsp siderne lukker con i bunden fatter jeg ikke hvorfor jeg render ind i problemer.
Jeg ved maaske godt at min fremgangsmaade ikke just er optimal og derfor beder jeg vel naermest om hjaelp til at lave koden thread-safe og holde connection'en i live pr. bruger i stedet for pr. side.
Haaber nogen er klar paa at give en "stor" hjaelp her...
1) aabne en connection i starten af hver metode og lukke den i bunden af metoden.
(dette tror jeg vil goere systemet en del langsommere)
2) aabne en connection i starten af hver jsp side og sende den med i metoderne.
(dette giver et problem med for mange iframes/connections / connection refused)
Kan du uddybe lidt. Er min connection i context osv. ikke ok?
Underligt nok faar jeg ofte en fejl i linien som lukker forbindelsen (i bunden af en jsp) hvor den siger at forbindelsen er lukket... Men jeg har da laest mig frem til at en connection er aaben i laaang tid hvis man ikke lukker den.
Men basically er noget af det der goer min kode klodset nok at alle mine metoder er statiske. Ville det aendre noget hvis jeg instantierede Database-connection-objectet paa hver side i stedet for? altsaa i stedet for dette:
Connection con = SystemFunctions.getConnection(); DoThisAndThat(con);
Brugte dette:
SystemFunctions sf = new SystemFunctions(); Connection con = sf.getConnection(); DoThisAndThat(con);
eller skal jeg aabne/lukke i alle bagvedliggende metoder?
..hvis jeg lukker forbindelsen hele tiden bruger jeg jo ikke rigtig ideen med tomcats pooled connection, jeg ved bare ikke hvor jeg skal "holde" den aabne connection, og derfor var mit bedste bud i session :s
altsaa (for at skaere det ud i pap for mig) du synes jeg skal fjerne connection'en fra jsp siden og aabne/lukke en connection i hver metode i back-enden.
Er det saa ok at kalde connection metoden statisk fra enhver metode, eller skal jeg instantiere min SystemFunctions-klasse i hver metode og kalde den derfra (goere det ikke statisk). Det vil skabe en del instanser. Kan garbage-collectoren foelge med, eller skal jeg System.cg() en gang imellem?
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.