Nicholas wrote:
I have been perofmring some tests on the Commit OptionIn order to save portability try Seppuku pattern: http://www2.theserverside.com/patterns/thread.jsp?thread_id=11280&article_count=20
D. As I understand the docs, the comtainer will
periodically refresh the bean state from the database,
the frequency of that process being defined by the
default (30 seconds) or the <optiond-refresh-rate>
element.
However, I have observed that the event that is
triggered does not seem to actually refresh the bean
state, but rather simply invalidates it and forces a
trip to the database on the next bean access. Am I
totally off base here ? Obviously the former is
preferable.
Along those lines, I have some bean persistence store
tables that may periodically be updated by an external
source ( a legacy deal... ). I would really like to
give the legacy update middleware dudes an API to
publish JMS messages to MDBs that I set up that would
allow me to force Option D like refreshes (or at leat
invalidations). In this way, I reduce the likelihood
of lost updates or stale data being retrieved. The
communication mechansim aside, what would I need to do
inside the container to force a resynch like this ?
Thanks.
//Nicholas
=====
Nicholas Whitehead
Home: (973) 377 9335
Cell: (201) 615 2716
Work: (212) 622 5639
[EMAIL PROTECTED]
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
