All,
Since around OJB 1.0 RC 4, we have had some code that toggles the table that a ClassDescriptor is pointing to at runtime using the ClassDescriptor.setTableName(). The tables that we switch between have identical structure. As long as we took care of sequence manager issues, cleared the object cache, and released all broker instances, life seemed to be good. We could easily store objects of a single class into different tables at runtime ... SLICK!
Recently, though, when running some tests, I have found that switching the targeted table isn't working. One major difference in our application is that we have upgraded to OJB 1.0. I've done some debugging and found that now, for example, if I run any operations that cause an insert AND THEN switch the tablename and attempt another insert, I have problems. The problem is that OJB still wants to insert data into the original table that was configured before I switched the tablename. I did some digging and noticed that there was a good amount of refactoring in ClassDescriptor and it *appears* that the StatementsForClassImpl class is caching the SQL and causing the original SQL to be executed even after I change the tablename.
So here is the question: To anyone that knows the ClassDescriptor implementation and understands how OJB 1.0 caches statements and the SQL for them, does this new problem seem consistent with OJB 1.0's implementation? If so, do you have any ideas on how I can work around it?. I am contemplating writing my own version of StatementsForClassImpl that allows me to clear the cached SQL, but I want to make sure my diagnosis of the problem is correct before I go down that path.
Any help is much appreciated.
-- Jason
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
