[OOP] Verstandig om resultatenset --> array/arraylist

[Maethor2]

Zonder veel ervaring te hebben met Software-engineering moeten we voor onze opleiding een programma schrijven dat gebruik maakt van een database (java/access).

Momenteel maakten we om database te wijzigen/gegevens op te halen gebruik van een zelfgeschreven klasse met onder andere de volgende functies.

private void loadDriver() // Wordt uitgevoerd in constructor
private void connect()
private void closeConnection()

public void changeDatabase(String query) // Gebruikt executeUpdate en voert de query uit op de database
public ResultSet getResultset(String query)

De eerste twee functies zijn private en worden gebruikt in de volgende functies.

Het probleem is dat het onmogelijk is om een functie getResultSet te maken die een object van het type ResultSet retourneert nadat de databaseconnectie gesloten is. Het snel sluiten van de database is een prioriteit.

Een oplossing is om alles in een Array of Arraylist te stoppen, daarna de connectie te sluiten en de array/arraylist retourneren. Hier heb ik al een functie voor geschreven en die werkt.

Een andere oplossing is om connect() /closeConnection() public te maken, maar dan is de hele bedoeling van deze klasse weg. Namelijk een makkelijke manier aanbieden om met de database te werken zonder dat je je zorgen moet maken over ongesloten connecties, ...

Mijn vraag is of de array een goede oplossing is voor het probleem of hoe dit in de praktijk wordt aangepakt?

[Janoz]

In de praktijk wordt het openen in het sluiten van de connection niet zo ver 'weggestopt'. Het openen en sluiten is namelijk relatief duur. Zeker wanneer je meerdere queries achter elkaar wilt doen. Het is dus heel gebruikelijk dat het openen en het sluiten door de 'gebruiker' wordt afgehandeld omdat deze het beste weet wanneer hij de connectie nog nodig heeft. (Met gebruiker bedoel ik hier natuurlijk de gebruiker van je database class).

Een andere benadering zou kunnen zijn om met een callback te werken. Hoe dit precies in zijn werk gaat kun je zien in het JdbcTemplate wat in Spring zit.

[Maethor2]

Janoz schreef op dinsdag 30 november 2010 @ 20:40:
In de praktijk wordt het openen in het sluiten van de connection niet zo ver 'weggestopt'. Het openen en sluiten is namelijk relatief duur. Zeker wanneer je meerdere queries achter elkaar wilt doen. Het is dus heel gebruikelijk dat het openen en het sluiten door de 'gebruiker' wordt afgehandeld omdat deze het beste weet wanneer hij de connectie nog nodig heeft. (Met gebruiker bedoel ik hier natuurlijk de gebruiker van je database class).

Een andere benadering zou kunnen zijn om met een callback te werken. Hoe dit precies in zijn werk gaat kun je zien in het JdbcTemplate wat in Spring zit.

Meerdere query's na elkaar uitvoeren is voor het programma onnodig. Query's zullen maximaal eens in de tien seconden moeten uitgevoerd worden per eindgebruiker. In die tijd moet de connectie zeker gesloten zijn.

[RobIII]

Maethor2 schreef op dinsdag 30 november 2010 @ 20:59:
Meerdere query's na elkaar uitvoeren is voor het programma onnodig.

Nu nog wel

Als je je DB class vaker gaat gebruiken (en her-gebruiken, daarom doe je (ook) aan OOP) misschien niet. En het is helemaal geen probleem de verantwoordelijkheid bij de gebruiker (van de class) te leggen om expliciet aan te geven wanneer een connectie gesloten kan worden, dus wat Janoz zegt. Je kunt de connectie ook sluiten in de destructor/finalize (maar dan ben je afhankelijk van GC of het expliciet GC-en door de gebruiker) of in een IDisposable-achtig equivalent in Java (geen idee hoe 't daar precies zit).

Waarom is het sluiten van de connectie zo belangrijk? Je kunt ook aan connection pooling doen eventueel namelijk.

[ Voor 30% gewijzigd door RobIII op 30-11-2010 23:32 ]

[Razr]

Je zou misschien een iterator (die rijen uit de resultset retourneert) kunnen implementeren in je klasse? Als de iterator door de collectie heen is kunnen de resources worden opgeruimd en kan de connectie worden gesloten.

[ Voor 15% gewijzigd door Razr op 01-12-2010 00:21 ]

[Soultaker]

Maethor2 schreef op dinsdag 30 november 2010 @ 20:23:
Mijn vraag is of de array een goede oplossing is voor het probleem of hoe dit in de praktijk wordt aangepakt?

Het korte antwoord is: ja, op basis van de voorwaarden die je schetst lijkt me dit een prima oplossing.

Zoals genoemd is het normaalgesproken wel gebruikelijk om databaseconnecties langer open te laten (omdat het aanzienlijk kostbaarder is om de verbinding te maken dan 'm een tijdje open te houden) maar als je dat hier per se niet wil, lijkt dit me een simpele en doeltreffende oplossing.

[YopY]

Een 'design pattern' die ik zelf vaak toepas (als je het al een pattern mag noemen) is een ResultSetHandler. Dit is een object dat een ResultSet ontvangt en deze verwerkt, meestal om de resultaten in een Java object te plaatsen.

Ik zocht er eens naar, en het blijkt aanwezig te zijn in Apache Commons DBUtils, zie ResultSetHandler en de source van QueryRunner (regel ~385) voor een toepassingsvoorbeeld.

mbt het verhaal over het delen van verbindingen / meerdere queries uitvoeren over één verbinding, je kunt dit in een service laag omhullen:

Java:

public void doeIets() {
Connection conn = prepareConnection(); //QueryRunner heeft ook zoiets
ResultSetHandler result1 = new EenResultSetHandler();
ResultSetHandler result2 = new NogEenResultSetHandler();
QueryRunner.executeQuery(conn, "select * from y", result1);
QueryRunner.executeQuery(conn, "select * from z", result2);
closeConnection(conn);
}

zoiets.

[ Voor 30% gewijzigd door YopY op 01-12-2010 09:32 ]

[Maethor2]

Voor bepaalde zaken bleek het inderdaad nodig om vele queries na elkaar uit te voeren.Dit is opgelost door een andere functie toe te voegen die een array van queries verwerkt binnen 1 connectie die dan onmiddellijk gesloten wordt.Het is inderdaad de bedoeling om klassen te maken die opnieuw kunnen gebruikt worden, zonder dit echter werkelijk te doen.

We zijn bij de array gebleven. Het lost het probleem op zoals we het verwachten. Van een aantal zaken zoals connections poolen hebben we helemaal geen verstand.

Het sluiten van de databaseconnectie is belangrijk omdat er meerdere mensen tegelijk moeten gebruik van kunnen maken in hetzelfde programma en men ons verteld heeft dat dit niet kan met een .mdb database.

Bedankt voor de antwoorden. We hebben hier zeker wat aan gehad

[RobIII]

Maethor2 schreef op woensdag 01 december 2010 @ 23:56:
en men ons verteld heeft dat dit niet kan met een .mdb database

En wie is "men"? Want het kan wel degelijk. Dat Access nou niet super geschikt is daarvoor is andere koek; ik snap dan ook niet waarom men niet kiest voor een (zeg) SQL Express.

[Freeaqingme]

YopY schreef op woensdag 01 december 2010 @ 09:30:
Een 'design pattern' die ik zelf vaak toepas (als je het al een pattern mag noemen) is een ResultSetHandler. Dit is een object dat een ResultSet ontvangt en deze verwerkt, meestal om de resultaten in een Java object te plaatsen.

Ik ken dat als het Data Mapper Pattern, volgens mij hetzelfde...

[YopY]

Freeaqingme schreef op donderdag 02 december 2010 @ 00:13:
Ik ken dat als het Data Mapper Pattern, volgens mij hetzelfde...

Dat komt idd in de buurt (ResultSetHandler iig), maar dan nog met een laag erbovenop die verbinding opzet, query uitvoert en de verbinding weer afsluit. Maar ik geloof dat dat behoorlijk Java / JDBC-specifiek is.

[Maethor2]

RobIII schreef op donderdag 02 december 2010 @ 00:07:
[...]

En wie is "men"? Want het kan wel degelijk. Dat Access nou niet super geschikt is daarvoor is andere koek; ik snap dan ook niet waarom men niet kiest voor een (zeg) SQL Express.

De keuze is het gevolg van de momenteel gebrekkige infrastructuur. Het moet voor iedereen makkelijk toegankelijk zijn. Volgend jaar gaat men denk ik met een ander dbms werken.

[Freeaqingme]

Als "men" dat nu alvast doet, hoeven ze volgend jaar niet te switchen.

[Maethor2]

Freeaqingme schreef op donderdag 02 december 2010 @ 16:07:
Als "men" dat nu alvast doet, hoeven ze volgend jaar niet te switchen.

Het gaat hier over puur educatieve zaken, namelijk de aangeboden programma's/systemen die via platformen van de universiteit kunnen gebruikt worden. Momenteel laat dit niet toe dat er met veel andere alternatieven dan access gewerkt wordt. Volgend jaar komen er nieuwe studenten die andere programma's draaien met behulp van een ander dbms. Er hoeft dus niet echt "geswitched" te worden.

[Maniacs]

Ik weet niet hoe groot je database is, maar houd er rekening mee dat bij het gebruik van je huidige oplossing alle resultaten van je ResultSet in-memory geplaatst worden. Het zou schaalbaarder zijn om toch de ResultSet (of een iterable hierover) te exposen en je verder te verdiepen in connection pooling.
Hangt er dus een vanaf of je (inleer)gemak boven schaalbaarheid stelt in dit geval.