[Java] Connection pooling in een aparte virtual machine.

[Verwijderd]

Hallo allemaal.

Ik worstel al een paar weken met een probleem waar ik maar geen goede oplossing voor kan vinden.

Binnen mijn organisatie zijn we een client side applicatie aan het ontwikkelen welke gegevens trekt uit een RedBrick (Informix) database van IBM. Omdat we het aantal mogelijke connecties op de database willen beperken, willen we gebruik maken van connection pooling. Dit moet het mogelijk maken om (bijvoorbeeld) maximaal 8 connecties op de database toe te staan. Als een andere applicatie dan een connectie probeert te maken, moet deze in de wacht worden gezet totdat er weer een connectie vrij komt.

Nu is het mogelijk Connection Pooling op client niveau toe te passen of op server niveau (met behulp van een Application Server). Wij gebruiken hiervoor de freeware Application Server van jboss. Omdat het op client niveau niet mogelijk is een pool bij te houden voor meerdere clients, valt onze keuze op connection pooling op server niveau. Tot dusver geen probleem.

Nu wil het feit echter, dat we Connection Pooling via de Application Server (met behulp van JNDI) niet kunnen toepassen, omdat het niet mogelijk is connecties te krijgen buiten de virtual machine van de application server. Dit, omdat de client applicatie buiten de virtual machine van de application server draait.

Nu proberen we dit probleem te omzeilen door zelf een soort van server applicatie te bouwen welke in contact staat met de application server. Het idee is om de server applicatie een connectiepool te laten beheren door een connectie pool object te binden aan een referentie object op de application server. Als men dan als client de referentie van het object ophaalt vanaf de application server, zou het theoretisch mogelijk moeten zijn om op deze manier connecties op te halen en terug te zetten in de connectiepool die binnen de server applicatie beheert wordt.

Theoretisch, want het is erg moeilijk om zelf een connection pool op te zetten met de beschikbare jdbc driver van RedBrick.

Tot dusver mijn vrij uitgebreide omschrijving van het probleem

Ik ben niet zozeer op zoek naar een oplossing in code o.i.d., maar meer naar een mening van andere programmeurs die met hetzelfde probleem te kampen hebben gehad of nog steeds kampen.

Wat ik dus graag als reactie zou willen zien, is jullie mening over onze probleemomzeiling of wellicht een andere kijk op het verhaal met een andere oplossing.

Als iets niet duidelijk is m.b.t. de geschetste situatie, dan ben ik graag bereid het één en ander nog wat duidelijker te verklaren

Alvast bedankt!!!

[Verwijderd]

Verwijderd schreef op woensdag 29 december 2004 @ 12:19:
Nu wil het feit echter, dat we Connection Pooling via de Application Server (met behulp van JNDI) niet kunnen toepassen, omdat het niet mogelijk is connecties te krijgen buiten de virtual machine van de application server. Dit, omdat de client applicatie buiten de virtual machine van de application server draait

Hier ben ik je even kwijt...
Zeg je nou feitelijk dat je geen verbinding kunt leggen tussen client en (applicatie) server?

[Remus]

Valt dit niet te regelen met een intermediate applicatie zoals IDS Server:
http://www.idssoftware.com/idsserver.html
Dit programma buffert requests en voert ze als ik het goed heb uit via een verbinding met de database (hoewel dat misschien ook in te stellen valt).

[alienfruit]

Je zou een session-object kunnen kopelen aan een connectie, waarin je die referentie-object van de applicatie server kan opslaan. Vaak ondersteunt een DAL wel connection pooling out-of-the-box, en sessions, dit is in iedergeval wel waar onder Delphi en .NET.

[ Voor 34% gewijzigd door alienfruit op 29-12-2004 12:52 ]

[Verwijderd]

Als ik je goed begrijp wil je een Connection object aangemaakt op de server doorgeven aan de client. Dit is niet mogelijk omdat je Connection objecten niet pass by value door kunt geven aangezien ze niet serializable zijn. Wat je zou kunnen doen, in het geval je jboss gaat gebruiken, is een session bean maken die je connection object wrapt. Dus je implementeerd in die session bean alle methodes van Connection die je nodig hebt. Probleem hiermee is wel dat je waarschijnlijk ook ResultSet, PreparedStatement enzo moet gaan implementeren op de server.

Een andere oplossing is: Je maakt een kleine server die bijhoud hoeveel connecties er open zijn. Als je aan de client kant een connectie wil openen vraag je eerst aan de server hoeveel connecties er open zijn, zijn dit er meer dan 8 -> in de wacht zetten en periodiek vragen. Zijn dit er minder dan 8 -> gewoon via de client een connectie openen. Nadeel hiervan is dat je geen echte connection pool hebt.

Verder zou ik idd ook even die IDS server goed gaan bekijken, misschien is de functionaliteit die je zoekt hier wel gewoon aanwezig.

[Verwijderd]

Verwijderd schreef op woensdag 29 december 2004 @ 12:33:
[...]

Hier ben ik je even kwijt...
Zeg je nou feitelijk dat je geen verbinding kunt leggen tussen client en (applicatie) server?

Ik kan wel een lookup doen naar de datasource, maar ik krijg geen objecten terug. Volgens mij treed er zelfs een exceptie op als ik het probeer. Ik denk dat dit komt omdat JBOSS de datasource bind binnen zn eigen namespace waardoor deze alleen toegankelijk is binnen zijn eigen VM (de VM van de applicatie server dus). De reden dat ik geen object terug krijg, komt dus door het feit dat de client in een andere VM draait.

[Verwijderd]

Ah ik vat hem. Ik zou geen connecties over proberen te gooien, want dan moeten clienten ze ook weer vrij geven. Die logica behoort wat mij betreft dus allemaal thuis in de applicatie server. Message driven danwel een oplossing met stateless session beans lijkt mij een simpele gerechtvaardigde oplossing.

[Verwijderd]

Hoewel de IDS Server er uitziet als een uitstekende applicatie met idd vele mogelijkheden, ben ik bang dat het voor onze database niet echt bruikbaar zal zijn.

Zo is RedBrick bijvoorbeeld dan wel een Informix variant, toch werkt het allemaal net ff anders. Met een Informix JDBC driver kan ik bijvoorbeeld geen connectie krijgen met de database. Hoewel IDS met vele vele databases overweg kan, ben ik bang dat RedBrick daar niet bij zal zitten.

Daarnaast is voor dit project ons budget laag (oftewel...nihil) dus de aanschaf van een dergelijke applicatie is eigenlijk niet eens een overweging

Toch bedankt voor de suggestie......

[Standeman]

Je kan inderdaad geen connectie objecten via JNDI versturen. Maar mogelijk dat je je model naar de server toe verlpaatst. Dus vanaf je client roep je je model objecten op de client aan, dat zou volgens mij gewoon wel moeten werken. Of gewoon EJB's gebruiken.

Verder kan je nog kijken naar proxool.sourceforge.net. Is een OS connection Pool waar ik wel goede ervaringen mee hebt.

[ronaldmathies]

Waarom zou je geen Stateless Session Beans gebruiken (geen entity beans, dit is zonloos). Dan kan je gewoon de connection pool van JBoss laten werken en verders laat je alle query's door de EJB's uitvoeren met direct JDBC. Dit is naar mijn idee de meest simpele oplossing en de meest stabiele oplossing.

[Verwijderd]

Connections buiten je app.server gebruiken is geen goede zaak. Volgens mij is dit een typisch geval van een singleton DAO bouwen en die ontsluiten met een session bean (session facade).
Je client praat tegen die sessionfacade en heeft zelf geen weet van databases e.d. Ondersteunt die JDBC driver geen connection pooling dan kan je dat makkelijk in je DAO inbouwen.
Overigens werkt dit alleen als je een niet-geclusterde omgeving draait, met meerdere JVM's werkt de singleton truuk allicht niet (tenzij je connection pooling niet in je DAO hoeft te doen maar kan overlaten aan je app.server).

Als ik jou was zou ik een beetje inlezen in design patterns aangezien dit vrij standaard problemen zijn en waar dus ook standaard oplossingen voor zijn: http://java.sun.com/blueprints/patterns/

[ Voor 12% gewijzigd door Verwijderd op 29-12-2004 16:34 ]

[Verwijderd]

is XML-RPC of SOAP geen oplossing voor dit probleem?
(SOAP is "makkelijker", XML-RPC is "lichter")
je kan dan functies aanroepen vanuit je client die op de server worden uitgevoerd en de data terugkrijgen en het enige wat jouw client app ziet zijn gewone method-calls.

nog een voordeel is dat je makkelijk kan besluiten om meer of minder werk op de server te laten doen en de soap/xml-rpc server allerlei data kan laten cachen, zodat je de database minder belast.

gaat allemaal over HTTPS en/of HTTP dus ook geen firewall problemen.

let wel op dat je een goeie bandbreedte/server-cpu gebruik afweging maakt
(dus geen 100 losse rpc-requests maar 1 rpc-request met 100 data items b.v.)

RMI is misschien ook een kandidaat

[ Voor 97% gewijzigd door Verwijderd op 30-12-2004 15:24 ]