[j2ee / software-eng.] Persistance van factory-data

[oogapp0ltje]

Een topic met een vraag die ik wellicht ook had kunnen plaatsen onder Software Engineering & Architecture. Zelf vind ik mijn vraag meer implementatie gericht, ik zoek een geschikte implementatie voor een eigen persistance-laag, als jullie een idee hebben dat op architectuur-vlak efficienter is hoor ik dat heel graag!

Mijn idee is het volgende, ik heb een grote hoeveelheid 'business-objects' zoals Producten, Contacten, Accounts, Orders e.d. Ik wil voor mijn architectuur een hoge performance met betrekking tot de beschikbaarheid van deze data, de inbeslagnemende geheugenruimte neem ik voor lief. Kortom, mijn idee is om alle business-entities te laden uit een onderliggende database en deze opnemen in een Factory pattern die persistent in het geheugen blijft.

Mijn huidige implementatie ziet er ongeveer zo uit:


Echter ervaar ik nu het probleem dat wanneer ik meerdere BusinessFactories heb, de data uit een andere BusinessFactory instantie ook zichtbaar is in anderen (waar deze dus niet thuishoort). Compleet logisch natuurlijk als je bedenkt dat deze statische data van toepassing is op iedere navolgende instantie.

Mijn probleem is dus dat ik wel wil dat deze data actief blijft in het geheugen, maar de data binnen factories wel gescheiden blijft. Ik heb zo ongeveer alle mogelijk combinaties met 'static' variables uitgeprobeerd, geen enkele combinatie komt echter tot het mijn gewenste resultaat.

Ik zou natuurlijk een standaard persistance framework kunnen gebruiken als Hibernate, maar vanuit leerperspectief vind ik het nuttiger om dit zelf from-scratch te doen (ben nieuw in j2ee). Daarnaast weet ik ook niet of met hibernate de data 'actief' in het geheugen blijft of dat dit enkel een O/R laag is.

Hebben jullie een idee hoe ik dit probleem het beste kan oplossen? Zoals ik al zei kan het zijn dat mijn "factory-pattern" hier niet 'juist' is. Alle ideeen zijn van harte welkom

[ Voor 5% gewijzigd door oogapp0ltje op 15-04-2006 18:07 ]

[whoami]

PRG -> SE&A

Wat bedoel je hier eigenlijk met een 'factory'. Voor mij is een factory iets dat een ander object creeërt, maar ik denk dat jij het hier anders ziet ? Bij jou is de factory eigenlijk een in-memory store van je objecten, als ik het goed snap?

[oogapp0ltje]

whoami schreef op zaterdag 15 april 2006 @ 18:10:
PRG -> SE&A

Wat bedoel je hier eigenlijk met een 'factory'. Voor mij is een factory iets dat een ander object creeërt, maar ik denk dat jij het hier anders ziet ? Bij jou is de factory eigenlijk een in-memory store van je objecten, als ik het goed snap?

Ja wezenlijk gebruik ik mijn 'factory' klasse hier voor storage, de factorymanager herbergt functionaliteit die een jdbc-resultset vertaalt naar businessentities en stopt deze in businessfactory (verzamelklasse).
Ik weet niet of er een benaming is voor dit pattern, maar ik vond 'factory' het meest in de buurt komen, misschien niet helemaal politiek correct tough

Afgezien daarvan, zoek ik echter nogsteeds een mogelijkheid waarmee ik de collectie persistent kan maken. Iemand een idee?

[ Voor 11% gewijzigd door oogapp0ltje op 15-04-2006 22:30 ]

[momania]

Je zoekt volgens mij gewoon het DAO pattern: http://java.sun.com/blueprints/patterns/DAO.html

Kijk daar iig even goed na, om te zien of dat is wat je zoekt

[oogapp0ltje]

Ziet er inderdaad veelbelovend uit. Veel beter dan mijn idee maar aan voorbeeld te zien richt het DAO pattern zich meer op het scheiden van data en logica en abstractie van verschillende DBMSen.

Ik rest nogsteeds met de vraag hoe ik in een situatie als in mijn 1e post de gegevens persistent aanwezig kan maken na initialisatie van de servlets door de applicatieserver. Gegevens die als static gekenmerkt zijn blijven inderdaad heel mooi persistent, alleen gaat dat dus niet volledig op in mijn bovengenoemde situatie.

Het lijkt mij gewoon mooi om gegevens uit de database alleen tijdens initialisatie te laden in een datastructuur die gemakkelijk te benaderen is, zodat niet voor iedere request een berg query's naar de database gestuurd hoeft te worden.

[ Voor 20% gewijzigd door oogapp0ltje op 15-04-2006 22:51 ]

[momania]

Ravenof schreef op zaterdag 15 april 2006 @ 22:47:
Het lijkt mij gewoon mooi om gegevens uit de database alleen tijdens initialisatie te laden in een datastructuur die gemakkelijk te benaderen is, zodat niet voor iedere request een berg query's naar de database gestuurd hoeft te worden.

Uhm, kijk dan naar Hibernate
Hoef je je iig al geen zorgen te maken over de queries zelf, en voor dingen die vaak geladen moeten worden, zet je caching aan. Hibernate bepaald dan wel voor je of hij wel of geen queries uitvoert.

[oogapp0ltje]

momania schreef op zondag 16 april 2006 @ 01:44:
[...]

Uhm, kijk dan naar Hibernate
Hoef je je iig al geen zorgen te maken over de queries zelf, en voor dingen die vaak geladen moeten worden, zet je caching aan. Hibernate bepaald dan wel voor je of hij wel of geen queries uitvoert.

in mijn standaardpost wees ik al op de mogelijkheid voor hibernate, mede vanuit leerperspectief wil ik toch zelf proberen dit te maken. Ik kan altijd nog kijken naar hibernate.

[whoami]

Ravenof schreef op zaterdag 15 april 2006 @ 22:47:

Het lijkt mij gewoon mooi om gegevens uit de database alleen tijdens initialisatie te laden in een datastructuur die gemakkelijk te benaderen is, zodat niet voor iedere request een berg query's naar de database gestuurd hoeft te worden.

De naam van het pattern dat jij zoekt, is repository.

Echter, hetgeen jij wilt lijkt me niet zo handig in een multi-user scenario. Heb je daar al aan gedacht ?
Wat als user A iets wijzigt aan object 1 , en user B bekijkt daarna object 1 ?

Denk je dat het echt nodig is om alles in het geheugen in te laden bij application-startup ? Over hoeveel data spreken we hier eigenlijk ?

[Sammy]

Wat jij wil lijkt volgens mij erg op Object Prevalence. Een java-implementatie hiervan is te vinden op http://www.prevayler.org . Kort gezegd wordt alle data in het geheugen gehouden, met wel een transaction log op disk. Navigatie door je object-graph mag je zelf regelen (jxPath wordt genoemd als optie). Edits op je objects gebeuren volgens het Command pattern (oplossing voor probleem wat Whoami noemt), ACID properties krijg je van het framework. Misschien is het wat voor je.

[whoami]

Sammy schreef op zondag 16 april 2006 @ 13:30:
Edits op je objects gebeuren volgens het Command pattern (oplossing voor probleem wat Whoami noemt)

Ik zie niet in hoe het command pattern dat probleem kan oplossen ?

[Sammy]

whoami schreef op maandag 17 april 2006 @ 10:29:
[...]

Ik zie niet in hoe het command pattern dat probleem kan oplossen ?

Alle updates worden geserialiseerd uitgevoerd. Hoe er met 'dirty reads' wordt omgegaan weet ik eigenlijk ook niet, dus je hebt gelijk: dit alleen lost niet alles op.