Aaargh! BC4J issue: caches not clearing properly?

Question

Okay, I've spent a day on this already - perhaps someone can help?
In a nutshell:
I've designed myself a View Object and put it in an application module.
I programmatically execute the VO and loop through it deleting each row with remove();
I re-executeQuery on the View Object, and when I loop through it using while next() not null I get one row returned, even though I'd just deleted them all?!
But the real cruncher is, when I step through the code in debug mode my results are different: then (seemingly as long as I've given the IDE a rest between the getTransaction().commit() and the re-execution of the view), I get the correct 0 rows returned. (If instead I keep hitting f8 sufficiently quickly that the IDE can't keep up, I get 1 row returned.)
My hunch is that garbage collection is doing something in the gap, but I can't think what would that would be....
HELP!!!!! (Please.)
More info:
Imagine a Role table and an Operation table and the Role_Operation table effecting a many-to-many join between them. The view is drawn with the Role_Operation table as its "primary" entity, then it read-only-reference links to the Role and Operation entities to get the relevant descriptions. It's not an expert view. (Some of mine are because I'm using MySQL. What can I say? It was forced upon me!)
Things are a little less straightforward than the above (because I'm still using my real-world code) - between the delete and the re-query I use another simple view based on the role entity to update its description... I guess my next step will be to try it with this out.
When the problem originally surfaced after the commit I was checking the appmodule back into the pool (stateless) and checking it (the pool was giving me the same one) out again before requerying, so the problem seemed to survive that. I also tried setting the transaction's clearCacheOnCommit(true) and that didn't help.
I'm using JDeveloper 9.0.3 production release. I tried BC4J diagnostics and can't see any difference there. I've got MySQL logging queries and they seem to be the same (and give the correct results) in both cases (as you'd expect). I've run the code under Tomcat on both Oracle and Sun JVMs and get the erroneous row in both cases.
Any ideas????
Thanks, Mike.

Answer 1

Steve,
I've read your whitepaper several times. Each time a little more sinks in...
Passivation is unfortunately one for the future - I've been told to use MySQL and I'm doing everything statelessly...
IIRC, the whitepaper is in favour of passing the view objects directly to the JSP(view) layer, rather than (deep breath) using the view objects to access data to populate into collections of JavaBeans to pass to the view.
Based on the keep-it-simple principle I agree with you: it's a lot more straightforward to use a view object and as long as my application has a decent <i>logical</i> separation between the MVC layers I'm reasonably happy to forget a <i>physical</i> one. (It makes it a lot easier to explain to people coming from a non-J2EE direction; also, I think it'd be quite difficult to respond to an "Okay, so for every view-row we have you want me to define a Bean and before we forward to the JSP we pack everything into Beans and then in the JSP we unpack everything out of the Beans, and I'm doing this because it makes things easier?")
[Note that I don't consider that the ViewObject provides a hard physical separation because in the general case a JSP (view)layer could still add/update/delete rows and therefore affect the database/model.]
Beans seem to provide one real advantage above the fact that they provide type-safety at compile time (which BC4J does if you java-generate the row-class - which I have): once I've defined a bean I can populate it from anywhere I want.
I was trying to extend this "populate from anywhere" to ViewObjects. After all, once I've decided to use ViewObjects why do I want to use JavaBeans <i>at all</i> to pass anything to the JSP?
The particular scenario I was thinking of was where I've written a JSP to produce an HTML form containing all the current data about an entity, where the information is supplied to it in a view-row. The user then changes some of the values and asks to save..... but wait, there's an error in one of the fields! So what my application should do is redisplay the form (on which there's a message detailing the problem) along with all the "new" data that the user submitted. To have it do that, the simplest way is if I pass it the data in exactly the same way as I did to start - in a ViewObject. It seems to me that'll have to be the same ViewObject or I lose my type-safety, so I can't downgrade to AttributeList, and even if I could that'd mean almost identically duplicating many of the Views in my application.
And dammit... I've just seen that BC4J already allows this when you have statefulness. You can part populate the "database-linked" view-row and pass it back to the JSP. Dammit. But it doesn't help poor old stateless me: if I want that functionality I'll have to have the JSP expect either a VO <b>or</b> a bean-collection, or I'll have to extract everything into beans.
Two other things, not related to the above.
The first is that, despite having tried to take in as much documentation as I could, I didn't initially understand that when you use application modules to findViewObject you always get back the same VO and that if you change the Where clause then it affects all rowsets based on that VO. (In fact I'm not even exactly certain that what I just said is true - I just know I have to be careful!) This actually seems like slightly strange behaviour to me (and should be made clearer)! The reason being, in the same way as you said (elsewhere) that you'd taken to defining a method on the specific-view's Impl class to encapsulate the setting of the where-clause-parameters, I thought it made sense to have a number of methods encapsulating the setting of the parameters AND the where-clause itself. (And the order-by too!) In that way I have one view object, in general designed without a where clause, that allows me to execute it as VO.executeQuery() or VO.executeQueryForID(...) or VO.executeQueryOrderByDeptDesc().
Having read something that led me to the understanding above, I've taken to using findViewObject (or the container's getter when inside the AppModuleImpl, since this gives type-safety), getting its DefFullName via it's ViewDef object, and then using createViewObject to get my own copy (giving it a name that includes the name of the method that instantiated it, so I don't have to look for clashes beyond that method). I trust you approve?
Oh, and the second one is that I still don't exactly understand what the parameter means in SessionCookie's useApplicationModule(true/false), despite having read the javadoc. My best guess is that whichever I use the application module instance is dedicated for the use of only that session-cookie instance (until it's checked back in), but that if I use "true" to obtain a lock then the pool is going to block the same session-cookie from checking out that same(?) application module (probably from a different thread) until it's been checked back in?
Does that sound correct? (In my web-app I'm currently checking out my appmodules (in servlets) with a "true" argument.)
Phew! Sorry about all that feedback. I'm feeling bad that I'm slowing the book up...
Regards,
Mike.