/ Forside / Teknologi / Udvikling / Java / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Java
#NavnPoint
molokyle 3688
Klaudi 855
strarup 740
Forvirret 660
gøgeungen 500
Teil 373
Stouenberg 360
vnc 360
pmbruun 341
10  mccracken 320
Servlets - flytte/lukke database connectio~
Fra : Joergen Ramskov


Dato : 28-03-01 13:57

Jeg har en servlet-baseret application der benytter en connection
pool (DBConnectionBroker fra http://javaexchange.com/). Den bruges til
at connecte til forskellige databaser for at indtaste og hente
information.

Derudover har vi en anden (windows-baseret) applikation til at
håndtere oprettelse og nedlæggelse (m.m.) af databaser.

Problemet med webapplikationer som denne er at man ikke har særligt
meget kontrol over brugeren, dvs. man kan ikke altid vide en bruger
har lukket sin browser og dermed også applikationen.

Jeg vil gerne opnå at når en bruger logger korrekt af *eller* hvis der
opstår en sessiontimeout, så skal databaseforbindelserne nedlægges
(dvs. tilbageleveres til connection pool'en), og flyttes fra den
database den har fat i til en default database i stil med dette:

Connection con;
con..setCatalog(default);

Det skal gøres for at windows applikationen kan se om der er nogen der
har fat i en af databaserne. Behovet opstår hvis man feks. gerne vil
nedlægge en database.


/Jørgen Ramskov

 
 
Dennis Thrysøe (28-03-2001)
Kommentar
Fra : Dennis Thrysøe


Dato : 28-03-01 14:10



Joergen Ramskov wrote:

> Jeg vil gerne opnå at når en bruger logger korrekt af *eller* hvis der
> opstår en sessiontimeout, så skal databaseforbindelserne nedlægges
> (dvs. tilbageleveres til connection pool'en), og flyttes fra den
> database den har fat i til en default database i stil med dette:

Det er nemt nok når brugeren logger korrekt af, for så får du et request
at handle ud fra. Det er straks sværere med session-timeout.

Havde Servlet 2.3 bare været færdig og udbredt, så havde det været en leg.

Den eneste idé jeg lige kan komme på, kan lade sig gøre hvis man på en
eller anden måde kan få lov til at iterere over alle sessions. Så kunne
en selvstændig tråd vågne op en gang i mellem og sammenligne de
nuværende valide sessions med dem den regnede med der var der. Hvis en
session var væk skulle den tilhørende connection frigives.

Det skurer dog lidt i mine ører, at hver session skulle have sin egen
connection, hvis de alligevel er delt. Er det korrekt opfattet?

-dennis


Joergen Ramskov (29-03-2001)
Kommentar
Fra : Joergen Ramskov


Dato : 29-03-01 11:43

On Wed, 28 Mar 2001 15:09:56 +0200, Dennis Thrysøe <qabi@qabi.dk>
wrote:

>Det er nemt nok når brugeren logger korrekt af, for så får du et request
>at handle ud fra. Det er straks sværere med session-timeout.

Lige netop

>Havde Servlet 2.3 bare været færdig og udbredt, så havde det været en leg.

Fortæl, fortæl
Hvad er der af nyt i Servlet 2.3 der gør det let?
Jeg benytter Tomcat, så når Servlet 2.3 kommer på gaden (hvornår???)
og er implementeret i den, så kan jeg benytte den.

>Den eneste idé jeg lige kan komme på, kan lade sig gøre hvis man på en
>eller anden måde kan få lov til at iterere over alle sessions. Så kunne
>en selvstændig tråd vågne op en gang i mellem og sammenligne de
>nuværende valide sessions med dem den regnede med der var der. Hvis en
>session var væk skulle den tilhørende connection frigives.
>
>Det skurer dog lidt i mine ører, at hver session skulle have sin egen
>connection, hvis de alligevel er delt. Er det korrekt opfattet?

Nej, det skulle jeg ikke mene
Hver gang en session har behov for en connection, så henter den en hos
connection pool'en:

=== Cut ===
Connection con;
con = myBroker.getConnection();
=== Cut ===

og afleverer den igen bagefter:

== Cut ===
myBroker.freeConnection(con);
== Cut ===

Applikationen starter i en default database (path), der indeholder
oplysninger osv. om resten af databaserne (navn, brugernavn og
password til databasen, m.m.). Via path logger brugerne så ind på den
database de har behov for.

Jeg vil gerne have at så snart brugerne afslutter (på den ene eller
den anden måde), så skal DB forbindelserne gerne lukkes eller
"flyttes", så de peger på path databasen.

/Jørgen Ramskov

/Jørgen


Dennis Thrysøe (29-03-2001)
Kommentar
Fra : Dennis Thrysøe


Dato : 29-03-01 13:09



Joergen Ramskov wrote:

>> Havde Servlet 2.3 bare været færdig og udbredt, så havde det været en leg.
>
> Fortæl, fortæl

> Hvad er der af nyt i Servlet 2.3 der gør det let?

I Servlet 3.2 kommer der mulighed for at registrere listeners til den
slags events (session created, session timed out og meget andet).

> Jeg benytter Tomcat, så når Servlet 2.3 kommer på gaden (hvornår???)
> og er implementeret i den, så kan jeg benytte den.

Tomcat 4.0b 1 skulle indeholde en implementering af Servlet 2.3. Men den
er ikke nået produktions-kvalitet endnu.

>> Den eneste idé jeg lige kan komme på, kan lade sig gøre hvis man på en
>> eller anden måde kan få lov til at iterere over alle sessions. Så kunne
>> en selvstændig tråd vågne op en gang i mellem og sammenligne de
>> nuværende valide sessions med dem den regnede med der var der. Hvis en
>> session var væk skulle den tilhørende connection frigives.
>>
>> Det skurer dog lidt i mine ører, at hver session skulle have sin egen
>> connection, hvis de alligevel er delt. Er det korrekt opfattet?
>
>
> Nej, det skulle jeg ikke mene
> Hver gang en session har behov for en connection, så henter den en hos
> connection pool'en:
>
> === Cut ===
> Connection con;
> con = myBroker.getConnection();
> === Cut ===
>
> og afleverer den igen bagefter:
>
> == Cut ===
> myBroker.freeConnection(con);
> == Cut ===

Okay. Fint nok.


> Applikationen starter i en default database (path), der indeholder
> oplysninger osv. om resten af databaserne (navn, brugernavn og
> password til databasen, m.m.). Via path logger brugerne så ind på den
> database de har behov for.
>
> Jeg vil gerne have at så snart brugerne afslutter (på den ene eller
> den anden måde), så skal DB forbindelserne gerne lukkes eller
> "flyttes", så de peger på path databasen.

Ja, så kan jeg ikke gennemskue andet end hvad der svarer til en manuel
timeout. En tråd der vågner med et interval på f.eks. 30 sekunder og
checker om der er nogle connections der er timed ud. Hvis der er skal
denne tråd bare aflevere den til poolen.

-dennis


Joergen Ramskov (29-03-2001)
Kommentar
Fra : Joergen Ramskov


Dato : 29-03-01 13:56

On Thu, 29 Mar 2001 14:08:39 +0200, Dennis Thrysøe <qabi@qabi.dk>
wrote:

>> Jeg vil gerne have at så snart brugerne afslutter (på den ene eller
>> den anden måde), så skal DB forbindelserne gerne lukkes eller
>> "flyttes", så de peger på path databasen.
>
>Ja, så kan jeg ikke gennemskue andet end hvad der svarer til en manuel
>timeout. En tråd der vågner med et interval på f.eks. 30 sekunder og
>checker om der er nogle connections der er timed ud. Hvis der er skal
>denne tråd bare aflevere den til poolen.

Det var/er også den konklusion jeg er kommet til.
Der er dog noget jeg finder lidt sjovt:
Når jeg kalder "myBroker.freeConnection(con);", så holder den stadigt
fast i databasen, dvs. den connection (til den specifikke database)
bliver sådan set blot gjort tilgængelig for andre. Men det er måske
fordi "man" går ud fra at det altid er den samme database man vil have
forbindelse til?

/Jørgen Ramskov


Dennis Thrysøe (30-03-2001)
Kommentar
Fra : Dennis Thrysøe


Dato : 30-03-01 09:59

> Det var/er også den konklusion jeg er kommet til.
> Der er dog noget jeg finder lidt sjovt:
> Når jeg kalder "myBroker.freeConnection(con);", så holder den stadigt
> fast i databasen, dvs. den connection (til den specifikke database)
> bliver sådan set blot gjort tilgængelig for andre. Men det er måske
> fordi "man" går ud fra at det altid er den samme database man vil have
> forbindelse til?

Det er nok for at spare resourcer. Det dyreste der fidnes (I mange
sammenhænge) er at oprette en database forbindelse. Det kan snildt tage
op til et par sekunder eller 5. Brokeren er nok indrettet sådan, at den
kun 'låner' sine forbindelser ud efter behov. Låneren siger så selv til
når den er færdig.

Jeg vil da tro, at sådan en connection pool kan finde ud af om
forbindelserne er til samme database. Ellers skal de ikke I samme pool.

-dennis


Joergen Ramskov (30-03-2001)
Kommentar
Fra : Joergen Ramskov


Dato : 30-03-01 14:03

On Fri, 30 Mar 2001 10:59:18 +0200, Dennis Thrysøe <qabi@qabi.dk>
wrote:

>Det er nok for at spare resourcer. Det dyreste der fidnes (I mange
>sammenhænge) er at oprette en database forbindelse. Det kan snildt tage
>op til et par sekunder eller 5. Brokeren er nok indrettet sådan, at den
>kun 'låner' sine forbindelser ud efter behov. Låneren siger så selv til
>når den er færdig.
>
>Jeg vil da tro, at sådan en connection pool kan finde ud af om
>forbindelserne er til samme database. Ellers skal de ikke I samme pool.

Jeg benytter MySQL og har et dynamisk antal databaser (feks. test1,
test2, test3).

Skal/bør jeg oprette en connection pool til hver database?

Dvs. jeg bør ikke benytte con.setCatalog("database"), hvis jeg
benytter en connection pool?

/Jørgen Ramskov

Dennis Thrysøe (02-04-2001)
Kommentar
Fra : Dennis Thrysøe


Dato : 02-04-01 07:40



Joergen Ramskov wrote:

> On Fri, 30 Mar 2001 10:59:18 +0200, Dennis Thrysøe <qabi@qabi.dk>
> wrote:
>
>
>> Det er nok for at spare resourcer. Det dyreste der fidnes (I mange
>> sammenhænge) er at oprette en database forbindelse. Det kan snildt tage
>> op til et par sekunder eller 5. Brokeren er nok indrettet sådan, at den
>> kun 'låner' sine forbindelser ud efter behov. Låneren siger så selv til
>> når den er færdig.
>>
>> Jeg vil da tro, at sådan en connection pool kan finde ud af om
>> forbindelserne er til samme database. Ellers skal de ikke I samme pool.
>
>
> Jeg benytter MySQL og har et dynamisk antal databaser (feks. test1,
> test2, test3).
>
> Skal/bør jeg oprette en connection pool til hver database?
>
> Dvs. jeg bør ikke benytte con.setCatalog("database"), hvis jeg
> benytter en connection pool?

Jeg vil vurdere, at det kommer an på den connection pool der bruges.
Hvis den kan håndtere forskelligtartede connections på samme tid, er det
sikkert okay. Måske det kan ses ud fra parametrene til kaldet, der
henter en forbindelse. Det kald må jo så skulle vide hvilken slags
connection (host/catalog/user osv.) man gerne vil have.

-dennis


Thorbjørn Ravn Ander~ (02-04-2001)
Kommentar
Fra : Thorbjørn Ravn Ander~


Dato : 02-04-01 18:33

Joergen Ramskov wrote:

>
> Skal/bør jeg oprette en connection pool til hver database?

Lige præcis MySQL er meget hurtig til at lave forbindelser, og derfor
behøver du måske ikke lave alle de krumspring.

Hvor lang tid tager det dig at lave en forbindelse?

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
http://bigfoot.com/~thunderbear

Soren 'Disky' Reinke (03-04-2001)
Kommentar
Fra : Soren 'Disky' Reinke


Dato : 03-04-01 07:52

> > Skal/bør jeg oprette en connection pool til hver database?
>
> Lige præcis MySQL er meget hurtig til at lave forbindelser, og derfor
> behøver du måske ikke lave alle de krumspring.
>

Det er korrekt at den er hurtig til det, men hvis man nu laver noget
fornuftig generisk kode, hvor man bare angiver en databasedriver så ordner
den selv resten. Er det meget fornuftigt at lave en connection pool.
Det kan jo være ens kode skal bruges på en kommerciel database engang, som
måske slet ikke kører på samme maskine som java serveren.
Og jo færre round-trips til database serveren des bedre.

--
With many Thanks

Soren ' Disky ' Reinke ICQ #1413069 remove 'ihsyd' when email replying



Allan Unnerup (03-04-2001)
Kommentar
Fra : Allan Unnerup


Dato : 03-04-01 11:09


>> Lige præcis MySQL er meget hurtig til at lave forbindelser, og derfor
>> behøver du måske ikke lave alle de krumspring.
>
>Det er korrekt at den er hurtig til det, men hvis man nu laver noget
>fornuftig generisk kode, hvor man bare angiver en databasedriver så ordner
>den selv resten. Er det meget fornuftigt at lave en connection pool.
>Det kan jo være ens kode skal bruges på en kommerciel database engang, som
>måske slet ikke kører på samme maskine som java serveren.
>Og jo færre round-trips til database serveren des bedre.

Jeg benytter p.t. MySQL uden connection pool, og jeg kan bekræfte at
connections går over stok og sten. Der er dog endnu tale om et testsystem,
som endnu ikke er sat i produktion. Jeg leder i øjeblikket efter en
fornuftig connection pool, for det tilfælde at det skulle blive aktuelt, når
der kommer belastning på.

Jeg har valgt at køre uden connection pool indtil det bliver et problem.

Hilsen Allan



Thorbjørn Ravn Ander~ (03-04-2001)
Kommentar
Fra : Thorbjørn Ravn Ander~


Dato : 03-04-01 17:56

Soren 'Disky' Reinke wrote:

> Det er korrekt at den er hurtig til det, men hvis man nu laver noget
> fornuftig generisk kode, hvor man bare angiver en databasedriver så ordner
> den selv resten. Er det meget fornuftigt at lave en connection pool.
> Det kan jo være ens kode skal bruges på en kommerciel database engang, som
> måske slet ikke kører på samme maskine som java serveren.
> Og jo færre round-trips til database serveren des bedre.

Altsammen korrekt.

Hvilken MySQL-driver kender du som understøtter connection pools på en
standard måde?

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
http://bigfoot.com/~thunderbear

Soren 'Disky' Reinke (04-04-2001)
Kommentar
Fra : Soren 'Disky' Reinke


Dato : 04-04-01 07:35


"Thorbjørn Ravn Andersen" <thunderbear@bigfoot.com> wrote in message
news:3ACA0099.FDF78387@bigfoot.com...
> Soren 'Disky' Reinke wrote:
>
> > Det er korrekt at den er hurtig til det, men hvis man nu laver noget
> > fornuftig generisk kode, hvor man bare angiver en databasedriver så
ordner
> > den selv resten. Er det meget fornuftigt at lave en connection pool.
> > Det kan jo være ens kode skal bruges på en kommerciel database engang,
som
> > måske slet ikke kører på samme maskine som java serveren.
> > Og jo færre round-trips til database serveren des bedre.
>
> Altsammen korrekt.
>
> Hvilken MySQL-driver kender du som understøtter connection pools på en
> standard måde?

ingen, jeg laver Connection pool selv

--
With many Thanks
Soren ' Disky ' Reinke ICQ #1413069 remove 'ihsyd' when email replying
Please visit my Freshwater Aquaria Webpage
http://www.disky-design.dk/fish



Thorbjørn Ravn Ander~ (04-04-2001)
Kommentar
Fra : Thorbjørn Ravn Ander~


Dato : 04-04-01 18:01

Soren 'Disky' Reinke wrote:

> > Hvilken MySQL-driver kender du som understøtter connection pools på en
> > standard måde?
>
> ingen, jeg laver Connection pool selv

På en driveruafhængig måde? Interessant.

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
http://bigfoot.com/~thunderbear

Kasper Nielsen (29-03-2001)
Kommentar
Fra : Kasper Nielsen


Dato : 29-03-01 18:18


"Dennis Thrysøe" <qabi@qabi.dk> wrote in message
news:3AC325C7.9080405@qabi.dk...
>
> Tomcat 4.0b 1 skulle indeholde en implementering af Servlet 2.3. Men den
> er ikke nået produktions-kvalitet endnu.

Nej, og vi kommer hen i november førend der kommer en Catalina (Tomcat 4.0)
Final.

Problemet er, at den ikke må 'udgives' førend Servet 2.3 specifikationerne
er endeligt frigivet.

Mit gæt er, at den er nogenlunde klar om 2-3 måneder.

- Kasper



Morten Jensen (04-04-2001)
Kommentar
Fra : Morten Jensen


Dato : 04-04-01 16:22

Dennis Thrysøe wrote:
>
> Joergen Ramskov wrote:
>
> >> Havde Servlet 2.3 bare været færdig og udbredt, så havde det været en leg.
> >
> > Fortæl, fortæl
>
> > Hvad er der af nyt i Servlet 2.3 der gør det let?
>
> I Servlet 3.2 kommer der mulighed for at registrere listeners til den
> slags events (session created, session timed out og meget andet).

Hmm.. Javadoc på HttpSession (i Servlet 2.2) siger:

"When an application stores an object in or removes an object from a
session, the session checks whether the object implements
HttpSessionBindingListener. If it does, the servlet notifies the object
that it has been bound to or unbound from the session."

Jeg har ikke checket det, men det kunne jo godt tænkes, at værdierne
bliver korrekt "unbound", når sessionen timer ud og
HttpSessionBindingListener'en bliver kaldt.

--
CAPUT A/S Morten Jensen Phone +45 70 12 24 42
Nygade 6 Senior Developer Fax +45 70 11 24 42
DK-1164 Kbh K jensen@caput.com http://www.caput.com

Ole Nielsby (11-04-2001)
Kommentar
Fra : Ole Nielsby


Dato : 11-04-01 23:57


Morten Jensen <jensen@caput.com> skrev:

> Hmm.. Javadoc på HttpSession (i Servlet 2.2) siger:
>
> "When an application stores an object in or removes an object from a
> session, the session checks whether the object implements
> HttpSessionBindingListener. If it does, the servlet notifies the object
> that it has been bound to or unbound from the session."
>
> Jeg har ikke checket det, men det kunne jo godt tænkes, at
> værdierne bliver korrekt "unbound", når sessionen timer ud
> og HttpSessionBindingListener'en bliver kaldt.

Jamen det gør de da. Jeg har prøvet det med un-poolede
connections til InstantDB (som jeg i mellemtiden har droppet
til fordel for MySQL på grund af elendig dokumentation).
InstantDB fortæller på konsollen når en database lukkes.

ON/***Fjern slimdyret fra min svaradresse***



Allan Unnerup (29-03-2001)
Kommentar
Fra : Allan Unnerup


Dato : 29-03-01 15:33

>Den eneste idé jeg lige kan komme på, kan lade sig gøre hvis man på en
>eller anden måde kan få lov til at iterere over alle sessions. Så kunne
>en selvstændig tråd vågne op en gang i mellem og sammenligne de
>nuværende valide sessions med dem den regnede med der var der. Hvis en
>session var væk skulle den tilhørende connection frigives.

Skal jeg forstå det således, at DBConnectionBroker fra
http://javaexchange.com/ genererer flere og flere åbne connections
efterhånden som tiden går, hvis brugeres ikke logger korrekt af?

Hilsen Allan



Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408847
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste