Re: java.sql.SQLRuntimeException: Cannot store DataSet instance to WeakHashMap
The following message is a courtesy copy of an article that has been posted to comp.lang.java.databases as well. I'm cc'ing this reply to derby-user@db.apache.org, since not many derby people follow this newsgroup. Harri Pesonen [EMAIL PROTECTED] writes: I get the following error (sometimes) when I use DataSetsometype with Derby 10.2.1.0 and JDK6 b98: java.sql.SQLRuntimeException: Cannot store DataSet instance to WeakHashMap at com.sun.sql.QueryObject.registerDataSet(QueryObject.java:1306) at com.sun.sql.QueryObject.getQueryImpl(QueryObject.java:767) at com.sun.sql.QueryObject.access$000(QueryObject.java:26) at com.sun.sql.QueryObject$1.run(QueryObject.java:229) at java.security.AccessController.doPrivileged(Native Method) at com.sun.sql.QueryObject.invoke(QueryObject.java:224) at $Proxy5.system_Prefs_get(Unknown Source) at Kahvi.Kahvi.get_sys_pref(Kahvi.java:896) at Kahvi.Kahvi.get_sys_pref(Kahvi.java:892) at Kahvi.Kahvi.cache_filename(Kahvi.java:2627) at Kahvi.Kahvi.servletThumb(Kahvi.java:326) at Kahvi.thumb.processKahvi(thumb.java:23) at Kahvi.KahviServlet.processRequest(KahviServlet.java:66) at Kahvi.KahviServlet.doGet(KahviServlet.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:368) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NullPointerException at com.sun.sql.DataSetImpl$DataSetItr.init(DataSetImpl.java:1759) at com.sun.sql.DataSetImpl$DataSetListIterator.init(DataSetImpl.java:1846) at com.sun.sql.DataSetImpl.listIterator(DataSetImpl.java:1628) at java.util.AbstractList.equals(AbstractList.java:503) at java.util.WeakHashMap.eq(WeakHashMap.java:259) at java.util.WeakHashMap.put(WeakHashMap.java:406) at com.sun.sql.QueryObject.registerDataSet(QueryObject.java:1304) ... 32 more -- dt However, experience shows that for many people and many applications a dose of paranoia is reasonable - Bjarne Stroustrup
Re: java.sql.SQLRuntimeException: Cannot store DataSet instance to WeakHashMap
Hi all This is a JDK6 b98 problem, and not related to Derby. Bernt [EMAIL PROTECTED] wrote: The following message is a courtesy copy of an article that has been posted to comp.lang.java.databases as well. I'm cc'ing this reply to derby-user@db.apache.org, since not many derby people follow this newsgroup. Harri Pesonen [EMAIL PROTECTED] writes: I get the following error (sometimes) when I use DataSetsometype with Derby 10.2.1.0 and JDK6 b98: java.sql.SQLRuntimeException: Cannot store DataSet instance to WeakHashMap at com.sun.sql.QueryObject.registerDataSet(QueryObject.java:1306) at com.sun.sql.QueryObject.getQueryImpl(QueryObject.java:767) at com.sun.sql.QueryObject.access$000(QueryObject.java:26) at com.sun.sql.QueryObject$1.run(QueryObject.java:229) at java.security.AccessController.doPrivileged(Native Method) at com.sun.sql.QueryObject.invoke(QueryObject.java:224) at $Proxy5.system_Prefs_get(Unknown Source) at Kahvi.Kahvi.get_sys_pref(Kahvi.java:896) at Kahvi.Kahvi.get_sys_pref(Kahvi.java:892) at Kahvi.Kahvi.cache_filename(Kahvi.java:2627) at Kahvi.Kahvi.servletThumb(Kahvi.java:326) at Kahvi.thumb.processKahvi(thumb.java:23) at Kahvi.KahviServlet.processRequest(KahviServlet.java:66) at Kahvi.KahviServlet.doGet(KahviServlet.java:88) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:368) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.NullPointerException at com.sun.sql.DataSetImpl$DataSetItr.init(DataSetImpl.java:1759) at com.sun.sql.DataSetImpl$DataSetListIterator.init(DataSetImpl.java:1846) at com.sun.sql.DataSetImpl.listIterator(DataSetImpl.java:1628) at java.util.AbstractList.equals(AbstractList.java:503) at java.util.WeakHashMap.eq(WeakHashMap.java:259) at java.util.WeakHashMap.put(WeakHashMap.java:406) at com.sun.sql.QueryObject.registerDataSet(QueryObject.java:1304) ... 32 more -- Bernt Marius Johnsen, Database Technology Group, Staff Engineer, Technical Lead Derby/Java DB Sun Microsystems, Trondheim, Norway
10.2 licensing issue
I must report today that the restrictions imposed by the beta JDK license have not been lifted. As you know, the JDK 6 beta license requires a disclaimer that bars the use of the code for any productive use. This restriction is meant to forestall binary incompatibilities with the final, GA version of the JDK. These incompatibilities might arise due to late-breaking changes in the JDK during its beta cycle. Due to these late-breaking changes, applications compiled against earlier, beta versions of the JDK could behave erratically when run against the GA JDK. Such a disclaimer would need to appear in the NOTICES file of any Derby release built using the beta JDK's tools and libraries. This, in turn, is unacceptable for GA releases of Derby. Therefore at this time we cannot build a Derby release candidate which includes JDBC4 drivers--today those drivers can only be built using beta tools and libraries. For this reason, we, the Derby community must change our plan to ship imminently an official release of Derby that includes JDBC4. I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in 10.2, I think that (1) is a better plan. Of course, this is up to the community to decide. Regards, -Rick
Re: 10.2 licensing issue
Wow! Thanks for the update, Rick. I agree that option #1 (release 10.2 without JDBC 4) is best. -jean Rick Hillegas wrote: I must report today that the restrictions imposed by the beta JDK license have not been lifted. As you know, the JDK 6 beta license requires a disclaimer that bars the use of the code for any productive use. This restriction is meant to forestall binary incompatibilities with the final, GA version of the JDK. These incompatibilities might arise due to late-breaking changes in the JDK during its beta cycle. Due to these late-breaking changes, applications compiled against earlier, beta versions of the JDK could behave erratically when run against the GA JDK. Such a disclaimer would need to appear in the NOTICES file of any Derby release built using the beta JDK's tools and libraries. This, in turn, is unacceptable for GA releases of Derby. Therefore at this time we cannot build a Derby release candidate which includes JDBC4 drivers--today those drivers can only be built using beta tools and libraries. For this reason, we, the Derby community must change our plan to ship imminently an official release of Derby that includes JDBC4. I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in 10.2, I think that (1) is a better plan. Of course, this is up to the community to decide. Regards, -Rick
Re: 10.2 licensing issue
On 9/11/06, Rick Hillegas [EMAIL PROTECTED] wrote: I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in +1 to option one, then. Should we plan to have another release with JDBC 4 once JDK 1.6 ships? andrew
Re: 10.2 licensing issue
Andrew McIntyre wrote: On 9/11/06, Rick Hillegas [EMAIL PROTECTED] wrote: I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in +1 to option one, then. Should we plan to have another release with JDBC 4 once JDK 1.6 ships? andrew +1 I think that would be a great idea. Regards, -Rick
Re: 10.2 licensing issue
Rick Hillegas wrote: I can see two alternatives for us: 1. Ship 10.2 on the current schedule but do not include the JDBC4 drivers. When run on Java SE 6, Derby 10.2 would continue to expose our JDBC3 implementation. In addition, we would remove JDBC4-specific documentation from our user guides and prune out the JDBC4-specific javadoc. 2. Delay the current 10.2 schedule until after JDK 6 goes GA. At that time we could release a version of Derby which includes JDBC4 drivers. Given the length of time since 10.1 was released, the uncertainty of the exact date of JDK 6 shipment, and the number of new features included in 10.2, I think that (1) is a better plan. Of course, this is up to the community to decide. I do not think we have enough user feedback for 10.2 release just based on regression risk. We heard that the JDO tests passed and the Torque tutorial ran. We got a few questions on the list about how to upgrade. We got serious feedback from a single user who reported multiple serious optimizer regressions. That's it as far as I can tell from users. We got quite a few regression reports from development that folks stumbled upon. Many of these regressions sadly have already made their way into 10.1.3 and therefore are being picked up by users for production. If this were a medical trial for a blood pressure medicine and not a database what would we do? Our one patient in the trial of our next generation medication is finding multiple issues that have made him very sick and we find that many of these same regressions are in pharmacies now. I think we need to notify the user community of the situation, try to get more user input on 10.2 and flush out more regressions. We port fixes to 10.1 to try to get it to a stable state and then release 10.2. Also any ideas anyone has for new optimizer tests would be good and folks could write those. Those are all my ideas for now. It could be that lots of users have tried 10.2 without problems but haven't reported in and then it is just a matter of getting them to speak up. I will work to rattle the bushes around here and please ping groups where you work and ask them to try 10.2. I will also send a message to the user list to try to get more user input. See feedback I know of at : http://wiki.apache.org/db-derby/RegressionSearchAndDestroy http://wiki.apache.org/db-derby/TenTwoApplicationTesting Kathey
Have you tried 10.2 beta?
Have you tried 10.2 beta? What were your results? Positive or negative or why it is not worth your time I'd like to know. The reason is this: Open source software development is based (as I understand it) on iterative feedback and involvement from users especially beta. Any regression might cause your mission critical app to grind to a halt.Maybe you embed Derby in medical equipment, maybe you run a bank, maybe you use it to organize your CD's. Whatever it is, if it is important to you, you should test 10.2 and make sure it will still runs to your expectations. Here is what we have heard so far from users on 10.2 - Michael Bouschen tried the JDO tests and jean the Torque tutorial. Both passed. - A single user Prasenjit Sarker has found multiple serious optimizer regressions - A few users have asked how to upgrade. Download the beta from: http://people.apache.org/~rhillegas/10.2.1.3-beta/ Please list the results of your 10.2 application testing at: http://wiki.apache.org/db-derby/TenTwoApplicationTesting File Jira entries for bugs and don't forget to list your results at: http://wiki.apache.org/db-derby/RegressionSearchAndDestroy Kathey
Re: Have you tried 10.2 beta?
Stephen Caine wrote: I followed your link to send in beta reports (http://wiki.apache.org/ db-derby/TenTwoApplicationTesting), but I could not find how to submit a report. Can you be more specific? Thanks Steven! And I assume all went well. This is great news. Please just edit the wiki and add a line to the table there under Record your Testing Please let us know if you have any trouble editing the page. Kathey
