Bugs item #992651, was opened at 2004-07-16 17:28 Message generated for change (Comment added) made by ari7419 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=992651&group_id=22866
Category: JBossCMP Group: v3.2 Status: Closed Resolution: Rejected Priority: 5 Submitted By: Ari Erin Miller (ari7419) Assigned to: Nobody/Anonymous (nobody) Summary: NoPassivationCachePolicy incompatible with optiond Initial Comment: I'm describing behavior in jboss-3.2.4 If you employ a policy of org.jboss.ejb.plugins.NoPassivationCachePolicy, the optiond-refresh-rate is completely ignored. Your data is never updated from the persistent store. Preferably, this issue should be fixed. optiond should reload the cached entities from the persistent store, without removing them from cache. If it isn't going to be fixed, the documentation should be changed to indicate that the only way to synch entities is to passivate them (which really shouldn't be true), so NoPassivationCachePolicy is incompatible with optiond- refresh-rate. And a log warning indicating that optionD will not refresh from the persistent store if you use the NoPassivationCachePolicy could save other users from going down this incompatible path. ---------------------------------------------------------------------- >Comment By: Ari Erin Miller (ari7419) Date: 2004-07-17 07:32 Message: Logged In: YES user_id=983531 As I understand it, the whole point of optiond-refresh-rate is to allow for making alterations to your persistent data store outside of the application, and then, after a time specified by refresh rate, being able to see that change within the application. That is the expected behavior when using option D. The application server is not behaving in the expected manner when using option D and the NoPassivationCachePolicy. Synching an entity with the persistent data store shouldn't require passivating it. If you use the NoPassivationCachePolicy to keep all the entities in cache, optiond-refresh-rate simply doesn't work. You can update your persistent data store, wait for a time greater than the refresh rate, and you won't see the modification you made in the application. As a hypothetical example of why this is so serious, let us say that you have a column in your user table indicating whether a user is active. You have not bothered to add functionality to the application to set a user to active, intending to do it through a sql interface to your data store in the rare instance where you need to. A user who was marked inactive then attempts to login, putting their user entity into cache. Going to the database and marking the user as active will not work in and of itself to allow the user to login. The only way you can activate the user at that point would be to stop the application server and restart it to clear the entity from cache. This is true even if you are using Option D for caching, which explicilty promises to resynch the cache with the persistent data store periodically, allowing for the type of manual sql changes described previously. option D promises to resynch the cache with the data store at an interval specified by the optiond-refresh-rate. There are no caveats in the documentation about this functionality. The application server doesn't resynch with the persistent data store if you are using the NoPassivationCachePolicy, even with option D in effect. When a documented feature doesn't work as described, it is a bug. If the bug isn't going to be fixed, at the very least it should be documented, and a warning should appear in the log when you attempt to use the mutually incompatible NoPassivateCachePolicy and Option D, indicating that option D does not work with a NoPassivationCachePolicy. ---------------------------------------------------------------------- Comment By: Alexey Loubyansky (loubyansky) Date: 2004-07-17 00:14 Message: Logged In: YES user_id=543482 It behaves as it is expected to. The documentation should describe it clearly. What you described does not make much sense to me. It's like commit option B with delayed-action, i.e. invalidate and keep it cached not right after the tx commits but after some time. What does it buy you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=992651&group_id=22866 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
