Bugzilla Version 2.16.7
Bugzilla Bug 1691
  not possible to specify the pooling parameter "cache-scheme" for Oracle connects
     Query page      Enter new bug
Bug#: 1691   Platform:   Reporter: martin-fuchs at gmx dot net (Martin Fuchs)
Product:   OS:   Add CC:
Component:   Version:   CC:
Remove selected CCs
Status: CLOSED   Priority:  
Resolution: FIXED   Severity:  
Assigned To: martin-fuchs at gmx dot net (Martin Fuchs)   Target Milestone:  
URL:
Summary:

Attachment Type Modified Status Actions
first version of a patch patch 2004-10-21 16:19 none Edit
new version of the patch, now supporting multiple add methods patch 2004-10-22 14:49 none Edit
fixed null pointer exceptions patch 2004-12-14 11:14 none Edit
updated patch patch 2005-03-05 10:21 none Edit
updated import statements patch 2005-03-05 10:21 none Edit
Test case in ZIP archive application/zip 2005-03-20 04:39 none Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 1691 depends on: 1628 Show dependency tree
Show dependency graph
Bug 1691 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments:


Leave as CLOSED FIXED
Reopen bug

View Bug Activity   |   Format For Printing

Description: Opened: 2004-07-21 15:49

To activate connection pooling using the Oracle JDBC driver, one has to use 
the "data-source" form of configuration. This is a correct example for a 
database configuration:

<database name="database" engine="oracle">
    <data-source class-name="oracle.jdbc.pool.OracleConnectionCacheImpl">
        <params URL="jdbc:oracle:thin: at localhost:1521:TEST" user="scott" 
password="tiger" />
    </data-source>
    ...
</database>

This activates Oracle connection pooling using the default parameters.


Optionally you can add additional parameters in <params> such as:

        cache-time-to-live-timeout="30"
        cache-fixed-wait-timeout="30"
        max-limit="10"


What doesn't work is to specify an caching scheme using:

    cache-scheme="OracleConnectionCacheImpl.DYNAMIC_SCHEME"

This results in an exception:    (using Castor 0.9.5.3)
java.lang.NumberFormatException: For input 
string: "OracleConnectionCacheImpl.FIXED_SCHEME"
at java.lang.NumberFormatException.forInputString(Unknown Source)
at java.lang.Integer.parseInt(Unknown Source)
at java.lang.Integer.<init>(Unknown Source)
at org.exolab.castor.xml.UnmarshalHandler.toPrimitiveObject
(UnmarshalHandler.java:3303)
at org.exolab.castor.xml.UnmarshalHandler.processAttribute
(UnmarshalHandler.java:2770)
at org.exolab.castor.xml.UnmarshalHandler.processAttributes
(UnmarshalHandler.java:2479)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:2147)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:1292)
at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
at org.apache.xerces.validators.common.XMLValidator.callStartElement
(XMLValidator.java:1197)
at org.apache.xerces.framework.XMLDocumentScanner.scanElement
(XMLDocumentScanner.java:1862)
at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch
(XMLDocumentScanner.java:1238)
at org.apache.xerces.framework.XMLDocumentScanner.parseSome
(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1035)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:605)
at org.exolab.castor.jdo.engine.DatabaseRegistry.loadDatabase
(DatabaseRegistry.java:235)
at org.exolab.castor.jdo.JDO.getDatabase(JDO.java:603)
at ScottTest.run(ScottTest.java:63)
at ScottTest.main(ScottTest.java:23)

It seems, Castor doesn't translate the expression constant into a numeric value.


The following option to specify a caching scheme doesn't work either:
    cache-scheme="1"

This results in another exception:
java.lang.IllegalArgumentException: Type conversion error: could not set value 
of cacheScheme(java.lang.Integer) with value of type java.lang.Integer
at org.exolab.castor.mapping.loader.FieldHandlerImpl.setValue
(FieldHandlerImpl.java:474)
at org.exolab.castor.xml.UnmarshalHandler.processAttribute
(UnmarshalHandler.java:2779)
at org.exolab.castor.xml.UnmarshalHandler.processAttributes
(UnmarshalHandler.java:2479)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:2147)
at org.exolab.castor.xml.UnmarshalHandler.startElement
(UnmarshalHandler.java:1292)
at org.apache.xerces.parsers.SAXParser.startElement(SAXParser.java:1376)
at org.apache.xerces.validators.common.XMLValidator.callStartElement
(XMLValidator.java:1197)
at org.apache.xerces.framework.XMLDocumentScanner.scanElement
(XMLDocumentScanner.java:1862)
at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch
(XMLDocumentScanner.java:1238)
at org.apache.xerces.framework.XMLDocumentScanner.parseSome
(XMLDocumentScanner.java:381)
at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1035)
at org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:605)
at org.exolab.castor.jdo.engine.DatabaseRegistry.loadDatabase
(DatabaseRegistry.java:235)
at org.exolab.castor.jdo.JDO.getDatabase(JDO.java:603)
at ScottTest.run(ScottTest.java:63)
at ScottTest.main(ScottTest.java:23)

This error occures, because the function setCacheScheme() excpects a 'long' 
parameter, not a parameter of type 'int'. And Castor doesn't convert it from 
java.lang.Integer to long.

------- Additional Comment #1 From Werner Guttmann 2004-08-09 08:31 -------
Martin, the second exception reported above definitely is genuine, and needs to 
be addressed. 

Please bear in mind that you won't be able to use an expression such as 

   cache-scheme="OracleConnectionCacheImpl.DYNAMIC_SCHEME"

at all, as we won't be able to access driver specific constants.



------- Additional Comment #2 From Martin Fuchs 2004-08-09 10:49 -------
> Please bear in mind that you won't be able to use an expression such as 
>  cache-scheme="OracleConnectionCacheImpl.DYNAMIC_SCHEME"
> at all, as we won't be able to access driver specific constants.

OK, I also thought so. It was just a try since I found this expression in some 
old mails to the topic.

------- Additional Comment #3 From Werner Guttmann 2004-08-11 03:19 -------
Just added a dependency on bug 1628, as clearly this problem would be resolved 
without any work if we committed bug 1628.

------- Additional Comment #4 From Werner Guttmann 2004-10-07 04:44 -------
Martin, as bug 1628 has been committed yesterday, can you please verify whether 
you are still seeing above problem? If not, this bug should be closed as a 
duplicate of bug 1628.

------- Additional Comment #5 From Martin Fuchs 2004-10-07 07:42 -------
Yes, it now works to add the "cache-scheme" parameter to the data-source 
configuration.

*** This bug has been marked as a duplicate of 1628 ***

------- Additional Comment #6 From Martin Fuchs 2004-10-20 12:56 -------
Reopened the bug.

Using the "cache-scheme" parameter with classes12.jar as JDBC driver works
without problems. But using the newer "ojdbc14.jar" JDK 1.4 JDBC drivers results
in the exception talked about above. Both drivers are from Oracle 9 and export
the same interface: There are two methods setCacheSchema(int) and
setCacheSchema(String) in oracle.jdbc.pool.OracleConnectionCacheImpl.

The problem is:
org.exolab.castor.xml.descriptors.CoreDescriptors.generateClassDescriptor()
expects to find only ONE set method, not more. It does not look at the parameter
types to find the correct method to call. It is just luck if the one or the
other is chosen. (dependent on in which order the methods are enumerated from
Java Reflection)

------- Additional Comment #7 From Werner Guttmann 2004-10-20 12:59 -------
Just added Keith to CC.

------- Additional Comment #8 From Martin Fuchs 2004-10-20 13:12 -------
Keith, what do you think about allowing more than one set method in
FieldHandlerImpl and choosing between them in selectWriteMethod() based on the
parameter type given? This would allow to call the correct setter method and
solve the problem with overloaded functions.

------- Additional Comment #9 From Martin Fuchs 2004-10-21 16:19 -------
Created an attachment (id=742)
first version of a patch

------- Additional Comment #10 From Martin Fuchs 2004-10-21 16:24 -------
Hi,
this is my first version of a patch to solve the problems using the approach
described above. Any comments are appreciated. The "cache-scheme" parameter
works with this patch. But I am not quite sure, I got all completely right and
there are no side unpredicted effects. Should there also be the possibility for
more than one "add" method in addition to the multiple set methods?

------- Additional Comment #11 From Martin Fuchs 2004-10-22 14:49 -------
Created an attachment (id=743)
new version of the patch, now supporting multiple add methods

------- Additional Comment #12 From Martin Fuchs 2004-10-23 04:37 -------
Created an attachment (id=744)
fixed null pointer exceptions

------- Additional Comment #13 From Werner Guttmann 2004-12-07 05:21 -------
Keith, can you please share your views with us wrt Martin's suggestion ?

------- Additional Comment #14 From Keith Visco 2004-12-07 09:14 -------
I think it's a good idea, +1.

------- Additional Comment #15 From Werner Guttmann 2004-12-08 02:47 -------
Iow, as long as we don't break the XML test suite, let's commit this change. And
let's amend the documentation to get across the message that element/attribute
order is relevant (once this patch has been committed). At least a FAQ entry
should be added ...

------- Additional Comment #16 From Martin Fuchs 2004-12-10 11:37 -------
I did run the test suite using CTFRun.bat and can't see any problems. It 
reports 159 test cases and no failures.

------- Additional Comment #17 From Werner Guttmann 2004-12-11 02:01 -------
Well, in this case, let me try to get this into the codebase this weekend .. ;-).

------- Additional Comment #18 From Werner Guttmann 2004-12-14 07:29 -------
Martin, can you please attach a new patch, as the current one can not be applied
(easily) anymore as the code base has changed in places you are touching as well.

------- Additional Comment #19 From Martin Fuchs 2004-12-14 11:14 -------
Created an attachment (id=821)
updated patch

OK, here is an up-to-date patch.

------- Additional Comment #20 From Werner Guttmann 2004-12-14 11:39 -------
Martin, would you mind if I moved this to 0.9.7, i.e. post 0.9.6 ?

------- Additional Comment #21 From Martin Fuchs 2004-12-14 12:02 -------
No problem. We are using our own version containing not yet commited patches 
anyways.  ;-)

------- Additional Comment #22 From Werner Guttmann 2004-12-14 12:09 -------
Thanks. I'll commit this against head once the 0.9.6 release tag has been
created. And you guys really surprise me ... first Gregory, now you. Never heard
of stable and tested releases .. ;-).

------- Additional Comment #23 From Martin Fuchs 2005-01-03 05:49 -------
> Never heard of stable and tested releases .. ;-).

Sure, I heared of this the one or the other time.
But running projects are always urgent and can't wait until release dates of 
third party libraries, which seem always to move until sometime in the future.  
*g*

------- Additional Comment #24 From Martin Fuchs 2005-03-05 10:21 -------
Created an attachment (id=956)
updated import statements

Werner, you wanted to commit this after the 0.9.6 release.

------- Additional Comment #25 From Werner Guttmann 2005-03-05 12:28 -------
Sure, will look into this .. well, this weekend .. ;-).

------- Additional Comment #26 From Werner Guttmann 2005-03-08 08:21 -------
Actually, why don't you re)assign this to yourself, and eventually commit this?

------- Additional Comment #27 From Werner Guttmann 2005-03-15 07:04 -------
Martin, I am sure you have a ready-to-use test case for your patch. Do you mind
attaching it ... as I'd really like to commit this asap ?

------- Additional Comment #28 From Martin Fuchs 2005-03-20 03:41 -------
Sorry for not answering faster. I will add my test case and commit the patch.

------- Additional Comment #29 From Martin Fuchs 2005-03-20 04:39 -------
Created an attachment (id=982)
Test case in ZIP archive

------- Additional Comment #30 From ralf joachim 2005-03-20 06:13 -------
Hi Martin, looks like you forgot to add your changes to src/etc/CHANGELOG.

What do you think, shouldn't we add your test to CTF test suit even if it is
only applicable for Oracle?

------- Additional Comment #31 From Martin Fuchs 2005-03-24 01:40 -------
What are you missing in the CHANGELOG?

------- Additional Comment #32 From ralf joachim 2005-03-24 05:57 -------
Sorry, I have overlooked your changes to CHANGELOG. It's all as it should be.

     Query page      Enter new bug
This is Bugzilla: the Mozilla bug system. For more information about what Bugzilla is and what it can do, see bugzilla.org.
Actions: New | Query | bug # | Reports   New Account | Log In