Thursday, June 14, 2001 09:07 AM
Let us put the problem in perspective:
If you DB is accessed exclusively through the EJB server, then the only way to change DB data is via the EJBs themselves. In that case, there is no reason to "listen to database changes" since the EJB server is taking care of state synchronization for you. Instead, you can just re-read the data in the EJB. The only exceptin is if you have trigger procedures set up in your database, but this is probably not a good idea since you should be working exclusively through the object layer (you can use JMS or some other notification mechanism instead).
If you have a shared RDBMS, then you can usually specify that the DB is shared in your EJBs' deployment descriptor and the server will adopt a conservative approach where it acquires exclusive locks on the DB records that it accesses and re-reads data from the DB at appropriate points. Again, in this case, there is no need to poll the DB.
Finally, if this last approach does not work for you because it creates too much performance overhead, then I suggest creating a thread outside the EJB container (either as a new JVM thread or as a separate process). This thread then listens for DB triggers (or, alternatively, polls the DB) and invokes the right methods on your EJB's remote interface to re-load the data. If you do this, however, you should be very careful, because it is possible for the state of the EJB to become unsynchronized with the DB (since the EJB server is not aware that anybody else has access to the DB).