Nabble - Derby

Re: Feedback requested on proposed change to documentation format

2008-10-06T08:07:05Z

Kim Haase wrote:

That says what DITA cannot do, but doesn't indicate any benefits of
docbook, what would be the benefits of switching?

Dan.

From forum: Apache Derby Developers

Re: Feedback requested on proposed change to documentation format

2008-10-06T07:58:15Z

Hi Kim,

+1 to a documentation format which lets us build indexes and
intra-document hotlinks. If we migrate to a new system, I hope that it
preserves the following features of the old system:

1) Is driven by an ant script. This would make it easy to integrate into
a master target which the release manager could use to build
documentation and code.

2) Only uses tools which come with Apache-compatible licenses.

3) Only uses tools which are easy to get off the web without a lot of
prep and license click-through.

Thanks,
-Rick

Kim Haase wrote:

>
> I'd like to know what the Derby community thinks about the possibility
> of changing the source format of the Derby documentation from DITA to
> DocBook and using a different build system. DocBook is a schema that
> can use an XML DTD, like that of DITA; see http://www.docbook.org/ for
> more information.
>
> Our DITA toolkit has some problems that the Derby community hasn't
> been able to solve with our current level of resources:
>
> - It does not allow us to create book indexes or to create live links
> between manuals. The feedback we've received is that this makes the
> documentation hard to use.
> - Links to tables usually don't work in the PDF or HTML Book versions.
> - Building the PDF and HTML Book versions of the docs causes errors
> and warnings that we can't seem to get rid of.
>
> Conversion of the documentation source to DocBook would be a one-time
> task that I'd be willing to take on. I can also use an existing
> DocBook build system that, like the DITA toolkit, uses only freely
> available open-source tools. The only change is that it would need to
> convert from Gnu make to Ant to be compatible with the Apache license.
> The goal would be to make it no more difficult to build the
> documentation than it is today (and ideally easier). I would hope to
> complete the project for the next release of Derby (10.5).
>
> Before I explore these possibilities further, I'd like feedback from
> the community. It seems that few people are currently working on the
> Derby documentation, but many of you are using it. I would be grateful
> for your thoughts.
>
> Kim Haase

From forum: Apache Derby Developers

[jira] Created: (DERBY-3900) SELECT ... FOR UPDATE cannot be used in many queries

2008-10-06T07:55:44Z

SELECT ... FOR UPDATE cannot be used in many queries
----------------------------------------------------

Key: DERBY-3900
URL: https://issues.apache.org/jira/browse/DERBY-3900
Project: Derby
Issue Type: Improvement
Reporter: Marco

The documentation in http://db.apache.org/derby/docs/10.4/ref/rrefsqlj41360.html#rrefsqlj41360__sqlj15384 says that SELECT ... FOR UPDATE cannot be used in many situations (e.g. when ORDER BY is present or when JOINs are used). I can very well understand that the current implementation using updatable cursors is very hard to implement when multiple tables are used and therefore these restrictions are probably necessary.

However, besides that functionality, "FOR UPDATE" is extremely useful for transactional integrity: For example, we - http://www.jfire.org - use transaction isolation level read committed, because it provides good transaction safety combined with good performance. When modifying records, we first select the appropriate table rows with a SELECT FOR UPDATE in order to guarantee that the data we just read cannot be manipulated by another transaction while we are working with it.

I do not see any reason why this locking behaviour should not be possible for certain queries. Therefore, I recommend to introduce a configuration setting (maybe a system property? or an option passed to the JDBC-URL?) that disables updatable queries completely (we don't need them anyway and probably it improves performance when not using them). With this option set, the SELECT ... FOR UPDATE should solely affect locks on rows - and work with all SELECT expressions - no matter whether they use JOIN, UNION, ORDER BY etc..

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Apache Derby Developers

Feedback requested on proposed change to documentation format

2008-10-06T07:39:07Z

I'd like to know what the Derby community thinks about the possibility
of changing the source format of the Derby documentation from DITA to
DocBook and using a different build system. DocBook is a schema that can
use an XML DTD, like that of DITA; see http://www.docbook.org/ for more
information.

Our DITA toolkit has some problems that the Derby community hasn't been
able to solve with our current level of resources:

- It does not allow us to create book indexes or to create live links
between manuals. The feedback we've received is that this makes the
documentation hard to use.
- Links to tables usually don't work in the PDF or HTML Book versions.
- Building the PDF and HTML Book versions of the docs causes errors and
warnings that we can't seem to get rid of.

Conversion of the documentation source to DocBook would be a one-time
task that I'd be willing to take on. I can also use an existing DocBook
build system that, like the DITA toolkit, uses only freely available
open-source tools. The only change is that it would need to convert from
Gnu make to Ant to be compatible with the Apache license. The goal would
be to make it no more difficult to build the documentation than it is
today (and ideally easier). I would hope to complete the project for the
next release of Derby (10.5).

Before I explore these possibilities further, I'd like feedback from the
community. It seems that few people are currently working on the Derby
documentation, but many of you are using it. I would be grateful for
your thoughts.

Kim Haase

From forum: Apache Derby Developers

[jira] Commented: (DERBY-3429) Remove system property derby.system.jmx

2008-10-06T07:25:44Z

[ https://issues.apache.org/jira/browse/DERBY-3429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637103#action_12637103 ]

Kristian Waagan commented on DERBY-3429:
----------------------------------------

I notice there are still references to "derby.system.jmx" in Derby source code comments.

> Remove system property derby.system.jmx
> ---------------------------------------
>
> Key: DERBY-3429
> URL: https://issues.apache.org/jira/browse/DERBY-3429
> Project: Derby
> Issue Type: Sub-task
> Components: JMX
> Reporter: Daniel John Debrunner
> Assignee: Daniel John Debrunner
> Priority: Minor
> Fix For: 10.4.1.3
>
>
> I don't believe that derby.system.jmx provides any benefit and is counter to the concept of using JMX for management.
> The one use case for it from DERBY-1387 is:
> Making the Derby JMX automatically available in the MBean server will make it impossible for the user to make some application with an embedded Derby db manageable thorugh JMX without also making Derby manageable thorugh JMX. I would think that this "all or nothing" granularity could be a problem for some applications. So we would need an explicit derby.system.jmx property for enabling the management service anyway.
> The functional spec contains no information as to why this is a useful feature.
> I wanted to separate out the discussion from the wider issues in DERBY-1387

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Apache Derby Developers

[jira] Commented: (DERBY-3887) Embedded Derby fails under JBoss because of JMX-related conflicts

2008-10-06T07:23:44Z

[ https://issues.apache.org/jira/browse/DERBY-3887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637102#action_12637102 ]

Marco commented on DERBY-3887:
------------------------------

We - http://www.jfire.org - have the same problem and assume that it is a caused by the deployment configuration: Because we use Derby for JBoss' messaging (JBossMQ), we have to put derby.jar into the lib directory (otherwise the JBossMQ fails with exceptions). However, the JMX seems to be in JBoss' deploy directory and therefore Derby has no chance to ever find the class (didn't verify this - just an assumption).

Additionally, it might be a problem with timing: When Derby is loaded, maybe the JMX is not yet started?

I don't know the best solution to this problem, but I know that we don't need JMX. That's why we deactivated this line mentioned above. However, patching a libraries JAR is not a nice way. Therefore, I'd like to ask for another - more convenient solution:

1) Instead of an exception, it should simply log a warning and continue (JMX isn't really essential - is it?).
2) It should be possible to provide a system property which deactivates the JMX hooking on startup (to get rid of the WARN log).

In the long run, it would be nice to have a clean solution that takes the said problems (deployment location + timing) into account.

> Embedded Derby fails under JBoss because of JMX-related conflicts
> -----------------------------------------------------------------
>
> Key: DERBY-3887
> URL: https://issues.apache.org/jira/browse/DERBY-3887
> Project: Derby
> Issue Type: Bug
> Components: JMX
> Affects Versions: 10.4.2.0
> Environment: Windows XP SP2, JBoss 4.2.3.GA, Embedder Derby 10.4.2.0.
> Also tested with JBoss 5.0.0.CR2 with the same result.
> Reporter: Valery Khromov
> Priority: Critical
>
> I'm trying to use embedded Derby as datasource for JBoss and found that it fails with error.
> See stacktrace below.
> It looks like JMX module in Derby conflicts with JBoss JMX.
> After I have disabled Derby JMX removing "derby.module.mgmt.jmx=org.apache.derby.impl.services.jmx.JMXManagementService" line from org\apache\derby\modules.properties file in derby.jar JAR, the bug disappears.
> How to reproduce the issue:
> 1). Install JBoss
> 2). Copy jboss\docs\examples\varia\derby-plugin.jar into jboss\server\default\lib
> 3). Copy Derby JAR (derby.jar) into jboss\server\default\lib
> 4). Copy datasource file into jboss\server\default\lib
> 5). Start JBoss using bin\run.bat
> Datasource file (zzzzz-ds.xml):
> ==={{{
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE datasources
> PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN"
> "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd">
> <datasources>
> <local-tx-datasource>
> <jndi-name>zzzzzDatasource</jndi-name>
> <driver-class>org.apache.derby.jdbc.EmbeddedDriver</driver-class>
> 
> <connection-url>jdbc:derby:IGNORED</connection-url>
> <user-name>IGNORED</user-name>
> <password>IGNORED</password>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>20</max-pool-size>
> <idle-timeout-minutes>5</idle-timeout-minutes>
> <track-statements/>
> <depends>jboss:service=zzzzzDerbyDB</depends>
> </local-tx-datasource>
>
> 
> <mbean code="org.jboss.jdbc.DerbyDatabase" name="jboss:service=zzzzzDerbyDB">
> <attribute name="Database">zzzzz</attribute>
> <attribute name="User">sa</attribute>
> <attribute name="Password"></attribute>
> </mbean>
> </datasources>
> ===}}}
> Part of JBoss log with error and stacktrace:
> ==={{{
> 02:40:28,031 INFO [DerbyDatabase] starting derby jdbc:derby:C:\opt\jboss-4.2.3.GA\server\default\data/derby/zzzzz;create=true
> 02:40:28,468 WARN [ServiceController] Problem starting service jboss:service=zzzzzDerbyDB
> java.lang.ExceptionInInitializerError
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at org.jboss.jdbc.DerbyDatabase.getConnection(DerbyDatabase.java:222)
> at org.jboss.jdbc.DerbyDatabase.startService(DerbyDatabase.java:189)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy42.start(Unknown Source)
> at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at sun.reflect.GeneratedMethodAccessor21.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy9.deploy(Unknown Source)
> at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
> at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
> at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
> at $Proxy0.start(Unknown Source)
> at org.jboss.system.ServiceController.start(ServiceController.java:417)
> at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy4.start(Unknown Source)
> at org.jboss.deployment.SARDeployer.start(SARDeployer.java:304)
> at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
> at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
> at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
> at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
> at $Proxy5.deploy(Unknown Source)
> at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
> at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
> at org.jboss.Main.boot(Main.java:200)
> at org.jboss.Main$1.run(Main.java:508)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: javax.management.JMRuntimeException: Failed to load MBeanServerBuilder class org.jboss.mx.server.MBeanServerBuilderImpl: java.lang.ClassNotFoundException: org/jboss/mx/server/MBeanServerBuilderImpl
> at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:480)
> at javax.management.MBeanServerFactory.getNewMBeanServerBuilder(MBeanServerFactory.java:511)
> at javax.management.MBeanServerFactory.newMBeanServer(MBeanServerFactory.java:298)
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:213)
> at javax.management.MBeanServerFactory.createMBeanServer(MBeanServerFactory.java:174)
> at sun.management.ManagementFactory.createPlatformMBeanServer(ManagementFactory.java:302)
> at java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:504)
> at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(Unknown Source)
> at org.apache.derby.impl.services.jmx.JMXManagementService$3.run(Unknown Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.derby.impl.services.jmx.JMXManagementService.findServer(Unknown Source)
> at org.apache.derby.impl.services.jmx.JMXManagementService.boot(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
> at org.apache.derby.iapi.services.monitor.Monitor.startSystemModule(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(Unknown Source)
> at org.apache.derby.impl.services.monitor.FileMonitor.<init>(Unknown Source)
> at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Unknown Source)
> at org.apache.derby.iapi.jdbc.JDBCBoot.boot(Unknown Source)
> at org.apache.derby.jdbc.EmbeddedDriver.boot(Unknown Source)
> at org.apache.derby.jdbc.EmbeddedDriver.<clinit>(Unknown Source)
> ... 110 more
> Caused by: java.lang.ClassNotFoundException: org/jboss/mx/server/MBeanServerBuilderImpl
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:169)
> at javax.management.MBeanServerFactory.loadBuilderClass(MBeanServerFactory.java:427)
> at javax.management.MBeanServerFactory.checkMBeanServerBuilder(MBeanServerFactory.java:465)
> ... 131 more
> 02:40:29,250 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=DataSourceBinding,name=DefaultDS' to JNDI name 'java:DefaultDS'
> 02:40:29,562 INFO [A] Bound to JNDI name: queue/A
> 02:40:29,562 INFO [B] Bound to JNDI name: queue/B
> 02:40:29,562 INFO [C] Bound to JNDI name: queue/C
> 02:40:29,562 INFO [D] Bound to JNDI name: queue/D
> 02:40:29,578 INFO [ex] Bound to JNDI name: queue/ex
> 02:40:29,593 INFO [testTopic] Bound to JNDI name: topic/testTopic
> 02:40:29,593 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
> 02:40:29,609 INFO [testDurableTopic] Bound to JNDI name: topic/testDurableTopic
> 02:40:29,609 INFO [testQueue] Bound to JNDI name: queue/testQueue
> 02:40:29,656 INFO [UILServerILService] JBossMQ UIL service available at : /127.0.0.1:8093
> 02:40:29,703 INFO [DLQ] Bound to JNDI name: queue/DLQ
> 02:40:29,875 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'
> 02:40:30,093 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console, warUrl=.../deploy/jmx-console.war/
> 02:40:30,250 ERROR [URLDeploymentScanner] Incomplete Deployment listing:
> --- MBeans waiting for other MBeans ---
> ObjectName: jboss:service=zzzzzDerbyDB
> State: FAILED
> Reason: java.lang.ExceptionInInitializerError
> Depends On Me:
> jboss.jca:service=ManagedConnectionFactory,name=zzzzzDatasource
> --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM ---
> ObjectName: jboss:service=zzzzzDerbyDB
> State: FAILED
> Reason: java.lang.ExceptionInInitializerError
> Depends On Me:
> jboss.jca:service=ManagedConnectionFactory,name=zzzzzDatasource
> 02:40:30,656 INFO [Http11AprProtocol] Starting Coyote HTTP/1.1 on http-127.0.0.1-8080
> 02:40:30,687 INFO [AjpAprProtocol] Starting Coyote AJP/1.3 on ajp-127.0.0.1-8009
> 02:40:30,703 INFO [Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181439)] Started in 23s:375ms

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Apache Derby Developers

Re: Perfroamnce of IN ( ... list ... ) statements

2008-10-06T05:03:47Z

Kristian Waagan wrote:

> On 06.10.08 10:53, Tim Dudgeon wrote:
>> Peter Ondruška wrote:
>>> What Derby version is it?
>>> How does it perform if you re-create index on foo_id column?
>>
>> The column in the primary key column, so has an index.
>
> Hello Tim,
>
> It would be helpful to know if compressing the table helps (or
> re-creating the index). The idea is to update the statistics used by the
> optimizer.
>
> I saw the question in an earlier post, but no reply. Which version of
> Derby are you using?

As I mentioned in separate response, this is in fact much improved in
letest Derby compared with what I was used to.

No need to persue any further.
Sorry for the confusion.

Tim

>
>
> regards,

From forum: Apache Derby Users

Re: Perfroamnce of IN ( ... list ... ) statements

2008-10-06T05:02:25Z

derby@... wrote:
> There was an issue with earlier versions of Derby, that was supposed to
> have been fixed.

You are right. I tested with Derby 10.4 and it now looks much better.
Sorry for the confusion.

Tim

>
>
>
> Even so, the performance of the IN clause where you have a large list is
> going to be an issue in most databases.
>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Peter Ondruška
> [mailto:peter.ondruska@...]
> *Sent:* Sunday, October 05, 2008 3:12 PM
> *To:* Derby Discussion
> *Subject:* Re: Perfroamnce of IN ( ... list ... ) statements
>
>
>
> What Derby version is it?
>
> How does it perform if you re-create index on foo_id column?
>
>
>
> p.
>
> On Sun, Oct 5, 2008 at 10:07 PM, Tim Dudgeon
> <tdudgeon@...
> <mailto:tdudgeon@...>> wrote:
>
> If I run a statement like this is Derby:
> SELECT COL1, COL2 FROM FOO WHERE FOO_ID IN ( 1, 31, ..... 4567)
> it seems unexpectedly slow. Its actually faster to retrieve each row
> individually using a for loop that it is to use the IN ( .. list ... )
> clause. This seems strange.
>
> Thanks
>
> Tim
>
>
>

From forum: Apache Derby Users

[jira] Commented: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:<2> but was:<5>

2008-10-06T04:11:45Z

[ https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637077#action_12637077 ]

Ole Solberg commented on DERBY-3561:
------------------------------------

Another variant?:
testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:<4> but was:<6>

http://dbtg.thresher.com/derby/test/10.4Branch/jvm1.6/testing/testlog/lin/701824-suitesAll_diff.txt

> testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:<2> but was:<5>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3561
> URL: https://issues.apache.org/jira/browse/DERBY-3561
> Project: Derby
> Issue Type: Bug
> Components: JMX, Regression Test Failure, Test
> Affects Versions: 10.4.1.3, 10.5.0.0
> Reporter: Mike Matrigali
> Assignee: John H. Embretsen
> Fix For: 10.4.2.1, 10.5.0.0
>
> Attachments: d3561_classesFix.diff, d3561_testPolicyFix.diff, Derby3561ReproStandalone.java, Derby3561ReproSuite_notForCommit.diff
>
>
> The following test has been failing consistently in the tinderbox runs since about build 636714, unfortunately the run right before this build failed so
> it may be from that one.
> first tinderbox failure I could find:
> http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
> most recent as of this report:
> http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
> There was 1 failure:
> 1) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:<2> but was:<5>
> at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
> at org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Apache Derby Developers

[jira] Closed: (DERBY-3895) Needs update of master for 'derbyall/derbynetmats/DerbyNet/derbynetmats/holdCursorJDBC30'?

2008-10-06T02:55:45Z

[ https://issues.apache.org/jira/browse/DERBY-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ole Solberg closed DERBY-3895.
------------------------------

> Needs update of master for 'derbyall/derbynetmats/DerbyNet/derbynetmats/holdCursorJDBC30'?
> ------------------------------------------------------------------------------------------
>
> Key: DERBY-3895
> URL: https://issues.apache.org/jira/browse/DERBY-3895
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure, Test
> Affects Versions: 10.5.0.0
> Environment: Derby: JRE - JDBC: Java SE 6 - JDBC 4.0
> SVN: 700948
> JVM: Sun Microsystems Inc.
> java version "1.6.0_06"
> Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
> Java HotSpot(TM) Client VM (build 10.0-b22, mixed mode)
> OS: Solaris 10 5/08 s10x_u5wos_10 X86 64bits
> SunOS 5.10 Generic_127128-11
> Reporter: Ole Solberg
> Assignee: Myrna van Lunteren
> Priority: Minor
> Fix For: 10.5.0.0
>
>
> http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/700948-derbyall_diff.txt :
> ********* Diff file derbyall/derbynetmats/DerbyNet/derbynetmats/holdCursorJDBC30.diff
> *** Start: holdCursorJDBC30 jdk1.6.0_06 DerbyNet derbynetmats:derbynetmats 2008-10-02 02:48:34 ***
> 1325 del
> < WARNING 01003: Null values were eliminated from the argument of a column function. :
> 1325a1325
> > WARNING 01003: Null values were eliminated from the argument of a column function.
> 1332 del
> < WARNING 01003: Null values were eliminated from the argument of a column function. :
> 1332a1332
> > WARNING 01003: Null values were eliminated from the argument of a column function.
> 1339 del
> < WARNING 01003: Null values were eliminated from the argument of a column function. :
> 1339a1339
> > WARNING 01003: Null values were eliminated from the argument of a column function.
> 1372 del
> < WARNING 01003: Null values were eliminated from the argument of a column function. :
> 1372a1372
> > WARNING 01003: Null values were eliminated from the argument of a column function.
> 1389 del
> < WARNING 01003: Null values were eliminated from the argument of a column function. :
> 1389a1389
> > WARNING 01003: Null values were eliminated from the argument of a column function.
> 1406 del
> < WARNING 01003: Null values were eliminated from the argument of a column function. :
> 1406a1406
> > WARNING 01003: Null values were eliminated from the argument of a column function.
> Test Failed.
> *** End: holdCursorJDBC30 jdk1.6.0_06 DerbyNet derbynetmats:derbynetmats 2008-10-02 02:48:44 ***

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Apache Derby Developers

Re: Perfroamnce of IN ( ... list ... ) statements

2008-10-06T02:22:40Z

On 06.10.08 10:53, Tim Dudgeon wrote:
> Peter Ondruška wrote:
>> What Derby version is it?
>> How does it perform if you re-create index on foo_id column?
>
> The column in the primary key column, so has an index.

Hello Tim,

It would be helpful to know if compressing the table helps (or
re-creating the index). The idea is to update the statistics used by the
optimizer.

I saw the question in an earlier post, but no reply. Which version of
Derby are you using?

regards,
--
Kristian

>
> Tim
>
>>
>> p.
>> On Sun, Oct 5, 2008 at 10:07 PM, Tim Dudgeon
>> <tdudgeon@...
>> <mailto:tdudgeon@...>> wrote:
>>
>> If I run a statement like this is Derby:
>> SELECT COL1, COL2 FROM FOO WHERE FOO_ID IN ( 1, 31, ..... 4567)
>> it seems unexpectedly slow. Its actually faster to retrieve each row
>> individually using a for loop that it is to use the IN ( .. list
>> ... ) clause. This seems strange.
>>
>> Thanks
>>
>> Tim
>>
>>
>

From forum: Apache Derby Users

Re: Perfroamnce of IN ( ... list ... ) statements

2008-10-06T01:58:26Z

derby@... wrote:
> There was an issue with earlier versions of Derby, that was supposed to
> have been fixed.
>
>
>
> Even so, the performance of the IN clause where you have a large list is
> going to be an issue in most databases.

I'm running against 3 different databases. With Oracle and MySQL IN
clause performance is satisfactory. With Derby it is not and its much
faster to retrieve each row individually, which seems to indicate that
something is amiss.

Tim

>
>
>
>
>
> ------------------------------------------------------------------------
>
> *From:* Peter Ondruška
> [mailto:peter.ondruska@...]
> *Sent:* Sunday, October 05, 2008 3:12 PM
> *To:* Derby Discussion
> *Subject:* Re: Perfroamnce of IN ( ... list ... ) statements
>
>
>
> What Derby version is it?
>
> How does it perform if you re-create index on foo_id column?
>
>
>
> p.
>
> On Sun, Oct 5, 2008 at 10:07 PM, Tim Dudgeon
> <tdudgeon@...
> <mailto:tdudgeon@...>> wrote:
>
> If I run a statement like this is Derby:
> SELECT COL1, COL2 FROM FOO WHERE FOO_ID IN ( 1, 31, ..... 4567)
> it seems unexpectedly slow. Its actually faster to retrieve each row
> individually using a for loop that it is to use the IN ( .. list ... )
> clause. This seems strange.
>
> Thanks
>
> Tim
>
>
>

From forum: Apache Derby Users

Re: @since tags in Derby code

2008-10-06T01:53:39Z

On 03.10.08 18:52, Daniel John Debrunner wrote:

> Kristian Waagan wrote:
>> Hello,
>>
>> In a patch I worked on, I came across JavaDoc where the first line of
>> the method documentation was "JDBC 3.0". This looks a bit odd in the
>> generated JavaDoc, so I decided to replace it with a @since tag.
>>
>> When reviewing the patch, Knut Anders raised the issue of which value
>> to use for the tag.
>> I used "1.4" - for Java 1.4, which was the release vehicle for JDBC 3.0.
>> Knut Anders suggests using a Derby version, for instance "Derby
>> 10.4.2.0".
>>
>> There seems to be several artifacts we could version against:
>> - Derby
>> - JDBC specification
>> - Java specification
>>
>> It would be nice if the community could discuss the general usage of
>> @since tags, and also which values/versions to use with it.
>> Note that the tag value is "free form" - any text can be used.
>
> Since the tag is free form and generally more information is better, I
> would think that whichever specifications and/or versions that make
> sense can be added, e.g.
>
> @since Derby 10.4, JDBC 4.0
>
> Dan.

Thanks to Rick and Dan for sharing their opinions.

I think using the Derby version as the primary value makes sense. Adding
the JDBC specification version also makes sense to me, since the
(observed) capabilities of a given Derby version can change depending on
the JDBC specification used in the runtime environment.

I have created DERBY-3899 to align the usage of existing @since tags.
The plan is to create a patch within a few days, waiting a bit to allow
others to have their say.

thanks,
--
Kristian

From forum: Apache Derby Developers

Re: Perfroamnce of IN ( ... list ... ) statements

2008-10-06T01:53:24Z

Peter Ondruška wrote:
> What Derby version is it?
> How does it perform if you re-create index on foo_id column?

The column in the primary key column, so has an index.

Tim

>
> p.
>
> On Sun, Oct 5, 2008 at 10:07 PM, Tim Dudgeon
> <tdudgeon@...
> <mailto:tdudgeon@...>> wrote:
>
> If I run a statement like this is Derby:
> SELECT COL1, COL2 FROM FOO WHERE FOO_ID IN ( 1, 31, ..... 4567)
> it seems unexpectedly slow. Its actually faster to retrieve each row
> individually using a for loop that it is to use the IN ( .. list
> ... ) clause. This seems strange.
>
> Thanks
>
> Tim
>
>

From forum: Apache Derby Users

[jira] Created: (DERBY-3899) Align usage of @since JavaDoc tags

2008-10-06T01:33:44Z

Align usage of @since JavaDoc tags
----------------------------------

Key: DERBY-3899
URL: https://issues.apache.org/jira/browse/DERBY-3899
Project: Derby
Issue Type: Task
Components: Miscellaneous
Affects Versions: 10.5.0.0
Reporter: Kristian Waagan
Priority: Minor
Fix For: 10.5.0.0

A request for comments was posted to the derby-dev mailing list on how to use the @since tags in Derby source code.
Mail thread: http://www.nabble.com/%40since-tags-in-Derby-code-td19798069.html

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Apache Derby Developers

[jira] Commented: (DERBY-3871) EmbedBlob.setBytes returns incorrect insertion count

2008-10-06T01:01:47Z

[ https://issues.apache.org/jira/browse/DERBY-3871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637038#action_12637038 ]

Kristian Waagan commented on DERBY-3871:
----------------------------------------

Committed patch 2a to trunk with revision 701979.

> EmbedBlob.setBytes returns incorrect insertion count
> ----------------------------------------------------
>
> Key: DERBY-3871
> URL: https://issues.apache.org/jira/browse/DERBY-3871
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.5.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.5.0.0
>
> Attachments: BlobSetBytesTestRepro.diff, derby-3871-1a_insertion_count.diff, derby-3871-2a-loop_fix.diff
>
>
> EmbedBlob.setBytes returns invalid insertion counts. According to the JavaDoc, it should return the number of bytes inserted. The current implementation seems to return the position in the Blob after the bytes have been written.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: Apache Derby Developers

RE: Perfroamnce of IN ( ... list ... ) statements

2008-10-05T15:35:28Z

There was an issue with earlier versions of Derby, that was supposed to have been fixed.

Even so, the performance of the IN clause where you have a large list is going to be an issue in most databases.

From: Peter Ondruška [mailto:peter.ondruska@...]
Sent: Sunday, October 05, 2008 3:12 PM
To: Derby Discussion
Subject: Re: Perfroamnce of IN ( ... list ... ) statements

What Derby version is it?

How does it perform if you re-create index on foo_id column?

On Sun, Oct 5, 2008 at 10:07 PM, Tim Dudgeon <tdudgeon@...> wrote:

If I run a statement like this is Derby:
SELECT COL1, COL2 FROM FOO WHERE FOO_ID IN ( 1, 31, ..... 4567)
it seems unexpectedly slow. Its actually faster to retrieve each row individually using a for loop that it is to use the IN ( .. list ... ) clause. This seems strange.

Thanks

Tim

From forum: Apache Derby Users

Re: Perfroamnce of IN ( ... list ... ) statements

2008-10-05T13:11:33Z

What Derby version is it?

How does it perform if you re-create index on foo_id column?

On Sun, Oct 5, 2008 at 10:07 PM, Tim Dudgeon <tdudgeon@...> wrote:

If I run a statement like this is Derby:
SELECT COL1, COL2 FROM FOO WHERE FOO_ID IN ( 1, 31, ..... 4567)
it seems unexpectedly slow. Its actually faster to retrieve each row individually using a for loop that it is to use the IN ( .. list ... ) clause. This seems strange.

Thanks

Tim

From forum: Apache Derby Users

Perfroamnce of IN ( ... list ... ) statements

2008-10-05T13:07:09Z

If I run a statement like this is Derby:
SELECT COL1, COL2 FROM FOO WHERE FOO_ID IN ( 1, 31, ..... 4567)
it seems unexpectedly slow. Its actually faster to retrieve each row
individually using a for loop that it is to use the IN ( .. list ... )
clause. This seems strange.

Thanks

Tim

From forum: Apache Derby Users

Slow performance of select count(*) from a_table

2008-10-05T13:01:51Z

I have a large table (24 million rows) and getting the row count with
select count(*) from a_table is taking about 50 seconds.
This seems surprising to me. Surely Derby is not going through every row
and counting them?

Tim

From forum: Apache Derby Users

Re: help me

2008-10-05T12:10:49Z

赵峰 wrote:
> Apache Derby Network Server － 10.4.2.0
> String sql="insert into test (id,name) value(1,?)";
> PreparedStatement ps=con.prepareStatement(sql);
> ps.setObject(1,null);
> ps.executeUpdate()

try something like this :

ps.setNull(1, Types.Integer);

From forum: Apache Derby Users

Re: help me

2008-10-05T11:05:23Z

> java.sql.SQLException: 不支持此类型。

Can you translate this into English for us?

Also, you can usually get more information by
modifying your program using this technique:
http://wiki.apache.org/db-derby/UnwindExceptionChain

thanks,

bryan

From forum: Apache Derby Users

Regression Test Report - Daily 701658 - Sun DBTG

2008-10-05T08:55:23Z

[Auto-generated mail]

*Daily* 701658/2008-10-04 18:01:13 MEST

Failed Tests OK Skip Duration Suite
-------------------------------------------------------
*Jvm: 1.6*
lin
0 10610 10610 0 1421.39% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 79.73% derbyall
0 2 2 0 283.94% compatibility
0 2 2 0 .% demoSuite
sles
0 10610 10610 0 886.44% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 69.33% derbyall
0 2 2 0 165.73% compatibility
0 2 2 0 .% demoSuite
sol
F:1,E:1 10610 10608 0 1460.27% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 72.66% derbyall
0 2 2 0 196.03% compatibility
0 2 2 0 .% demoSuite
solN+1
0 10610 10610 0 168.66% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 95.62% derbyall
0 2 2 0 188.81% compatibility
0 2 2 0 .% demoSuite
sparc
0 10610 10610 0 454.05% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 63.14% derbyall
0 2 2 0 172.26% compatibility
0 2 2 0 .% demoSuite
vista
0 9183 9183 0 80.77% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 90.71% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
vista-64
0 9183 9183 0 124.37% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 96.31% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
w2003
0 9183 9183 0 160.56% suitesAll
0 13 13 0 .% jdbcapiAutoLoad
0 12 12 0 .% JDBCDriversAll
0 13 13 0 .% JDBCDriversClient
0 12 12 0 .% JDBCDriversEmbedded
0 235 235 0 88.18% derbyall
NA NA NA NA compatibility
0 2 2 0 .% demoSuite
Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-701658.html
Attempted failure analysis in
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/701658_bySig.html

*Jvm: 1.5*
lin
0 236 236 0 76.54% derbyall
0 8852 8852 0 1108.93% suitesAll
sles
0 236 236 0 67.62% derbyall
0 8852 8852 0 622.67% suitesAll
sol
0 236 236 0 75.98% derbyall
F:1,E:0 8852 8851 0 896.98% suitesAll
solN+1
0 236 236 0 86.25% derbyall
0 8852 8852 0 901.25% suitesAll
sparc
0 236 236 0 63.40% derbyall
0 8852 8852 0 820.76% suitesAll
vista
0 236 236 0 68.08% derbyall
F:1,E:1 7425 7423 0 486.55% suitesAll
vista-64
0 236 236 0 96.44% derbyall
F:1,E:0 7425 7424 0 123.58% suitesAll
w2003
0 236 236 0 69.07% derbyall
0 7425 7425 0 326.09% suitesAll
Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-701658.html
Attempted failure analysis in
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/701658_bySig.html

*Jvm: 1.4*
lin
0 233 233 2 76.41% derbyall
0 8700 8700 0 1058.19% suitesAll
sles
0 233 233 2 68.44% derbyall
0 8700 8700 0 606.43% suitesAll
sol
0 233 233 2 74.29% derbyall
0 8700 8700 0 771.51% suitesAll
solN+1
0 233 233 2 86.89% derbyall
0 8700 8700 0 874.08% suitesAll
sparc
0 233 233 2 64.19% derbyall
0 8700 8700 0 886.83% suitesAll
vista
0 233 233 2 68.22% derbyall
0 7273 7273 0 481.31% suitesAll
vista-64
0 233 233 2 95.12% derbyall
0 7273 7273 0 123.03% suitesAll
w2003
0 233 233 2 69.87% derbyall
0 7279 7279 0 321.14% suitesAll
Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-701658.html
Attempted failure analysis in
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/701658_bySig.html

-------------------------------------------------------

Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/701658.txt

( All results in http://dbtg.thresher.com/derby/test/ )

From forum: Apache Derby Developers

[jira] Subscription: Derby: JIRA issues with patch available

2008-10-05T08:35:44Z

Issue Subscription
Filter: Derby: JIRA issues with patch available (11 issues)
Subscriber: derby-dev

Key Summary
DERBY-3894 Reference Manual: supported functions should be listed in JDBC escape syntax topic
https://issues.apache.org/jira/browse/DERBY-3894
DERBY-3847 Tuning Guide lacks information on turning off Derby property settings
https://issues.apache.org/jira/browse/DERBY-3847
DERBY-3875 Derby cannot replace a database after encountering corruption
https://issues.apache.org/jira/browse/DERBY-3875
DERBY-3886 SQL roles: ij show enabled and settable roles
https://issues.apache.org/jira/browse/DERBY-3886
DERBY-3879 Getting Started Guide has typo and version problems
https://issues.apache.org/jira/browse/DERBY-3879
DERBY-1764 Rewrite stress.multi as a JUnit test
https://issues.apache.org/jira/browse/DERBY-1764
DERBY-3842 Convert "org.apache.derbyTesting.functionTests.tests.store.holdCursorExternalSortJDBC30.sql" to junit.
https://issues.apache.org/jira/browse/DERBY-3842
DERBY-2822 Add caching of store stream length in StoreStreamClob, if appropriate
https://issues.apache.org/jira/browse/DERBY-2822
DERBY-3810 Create a simple Clob performance regression test
https://issues.apache.org/jira/browse/DERBY-3810
DERBY-3652 Derby does not follow the SQL Standard when trying to map SQL routines to Java methods.
https://issues.apache.org/jira/browse/DERBY-3652
DERBY-3738 Add more tests for legal/illegal commands in the different replication states
https://issues.apache.org/jira/browse/DERBY-3738

From forum: Apache Derby Developers

Re: How to export data?

2008-10-04T23:16:33Z

Amir Michail wrote:
> Hi,
>
> Is there an easy way to export derby data to another database say in
> the form of a csv file?
>
> Amir
>
>
Hi,

http://db.apache.org/derby/docs/10.4/tools/ctoolsimport16245.html

Narayanan

From forum: Apache Derby Users

How to export data?

2008-10-04T17:35:27Z

Hi,

Is there an easy way to export derby data to another database say in
the form of a csv file?

Amir

--
http://chatbotgame.com
http://numbrosia.com
http://twitter.com/amichail

From forum: Apache Derby Users