Bugs item #541323, was opened at 2002-04-09 00:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=541323&group_id=22866
Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Luke Taylor (luke_t) Assigned to: Luke Taylor (luke_t) Summary: CacheConnectionInterceptor PM life-cyle Initial Comment: CacheConnectionInterceptor isn't implementing the "stop" lifecycle method properly. It doesn't call "stop" on the the its delegate entity persistence manager if this has been set, so the implementation will not be cleaned up properly on undeploying. For example, if remove-table has been set to "true" with CMP, the table will not be dropped. It doesn't yet implement "create" and "destroy" (both are empty apart from "TODO"s) but I'm not sure if anything else is required here for now. ---------------------------------------------------------------------- >Comment By: Luke Taylor (luke_t) Date: 2002-04-09 02:20 Message: Logged In: YES user_id=369802 > I'd prefer to fix this problem by reversing the order of the > calls in EntityContainer in stop, and going back to the > previous implementation of CachedConnectionInterceptor. That makes sense. I spent some time working out that CachedConnectionInterceptor had sneaked in there at all! I kept wondering why I wasn't seeing stop being called on CMPPersistenceManager. I'll leave it in your safe (well, safer :) hands. I don't have a test case at the moment - CMP wasn't working correctly with remove-table=true. Would it be possible to modify an existing CMP test case, set remove-table to true and make sure that the table had gone when it was undeployed? That would probably cover quite a lot of useful stuff. ---------------------------------------------------------------------- Comment By: David Jencks (d_jencks) Date: 2002-04-09 02:00 Message: Logged In: YES user_id=60525 I'd prefer to fix this problem by reversing the order of the calls in EntityContainer in stop, and going back to the previous implementation of CachedConnectionInterceptor. Then pm.start will be called before CachedConnectionInterceptor inserts itself between Container and pm, and pm.stop will be called after CachedConnectionInterceptor removes itself from between Container and pm. create and destroy then dont' have to do anything (anyway destroy shouldn't deal with the pm, it has already given back the reference to the Container) With the current and original implementation, stop is getting called twice on CachedConnectionInterceptor. I am not thrilled with how I intercepted the calls (mostly store) to the pm, if anyone has a better idea please let me know. I'm trying checking that what I proposed works, do you have a testcase you could add to the testsuite? Thanks for figuring out what the problem is!! ---------------------------------------------------------------------- Comment By: Luke Taylor (luke_t) Date: 2002-04-09 01:27 Message: Logged In: YES user_id=369802 On stop in CacheConnectionInterceptor, I've called "stop" on the encapsulated persistence manager. Ditto for "destroy". Does that make sense. Anything else I should look out for, David? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=541323&group_id=22866 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
