Jan 31st, 2007, 11:59 AM
How to design a DB aware component...
Trying to figure out how to best architect a component with the following characteristics:
This component will be used by multiple threads in an ApplicationServer. It should be initialized at application startup as its initialization will be fairly expensive (via some type of SpringFactory); during the initialization, it must connect to the DataSource, retrieve initialization data from the DB, complete initialization and be a Singleton so it can be used quickly without expensive initialization every time. When external events modify its data in the DB, it must recognize the data change in the DB, read the fresh data from DB and RELOAD itself, then continue to live as a Singleton but with NEW data values...
Not sure about how to implement the notification mechanism to this component so it will recognize that its DB data has changed and that it's time to reload itself.... Would some type of Observer pattern work for me? Example please.
Would it be better to implement this component as an Entity EJB?
All ideas are welcome.
Jan 31st, 2007, 02:52 PM
I would have thought AOP would be a good idea or if you're using Hibernate you can use interceptors with this as well.
Jan 31st, 2007, 04:06 PM
Interceptors to intercept what?!
I understand some AOP concepts, but I'm not sure how to get the Event notification that the DB values have changed - what would I intercept and where?
Last edited by jdepaul; Jan 31st, 2007 at 06:47 PM.
Feb 1st, 2007, 02:49 AM
I wasn't thinking of this being trigger based, more intercepting. So instead of something being inserted into the database and then something being triggered to update your in-memory model. I was actually thinking more about intercepting the update requests to your dao. The problem here is if the transaction rolls back.
Feb 1st, 2007, 03:22 AM
Afaik, there are some databases and some drivers that allow this kind of event interception. Without native support for such stuff you need to work with triggers updating some "last change timestamp" table that you need to poll in your app to see if something changed in the mean time.
Feb 1st, 2007, 04:36 AM
Again, aspects provide a great support for handling native stuff transparently and seamlessly. Here native methods for event interception can be handled with AOP. We have implemented fast connection failover using native Oracle 10g FCF in a completely transparent manner using AOP. I had summarised some of my experience in InfoQ here ..
Originally Posted by dejanp