Results 1 to 6 of 6

Thread: How to design a DB aware component...

  1. #1

    Default 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.

    Thanks,
    James

  2. #2
    Join Date
    Sep 2006
    Location
    UK
    Posts
    8,425

    Default

    I would have thought AOP would be a good idea or if you're using Hibernate you can use interceptors with this as well.
    http://www.springframework.org/docs/reference/aop.html
    http://www.hibernate.org/48.html

  3. #3

    Default 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.

  4. #4
    Join Date
    Sep 2006
    Location
    UK
    Posts
    8,425

    Default

    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.

  5. #5
    Join Date
    Sep 2004
    Posts
    1,086

    Default

    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.

  6. #6
    Join Date
    Jul 2006
    Location
    Kolkata, India
    Posts
    217

    Default

    Quote Originally Posted by dejanp View Post
    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.
    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 ..

    HTH,
    - Debasish

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •