Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII; format=flowed
Date: Wed, 29 Jul 2009 18:40:39 +0200
From: Kristian Waagan <Kristian.Waagan@Sun.COM>
Subject: Re: Embedded Derby multi-user
In-reply-to: 
 <C02A47E990DE164EB17E7F7E15182615035349AB@logimail1.LogiXML.local>
Sender: Kristian.Waagan@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <4A707B87.6070509@Sun.COM>
References: <4A6E9D0E.3000403@Sun.COM>
 <C02A47E990DE164EB17E7F7E15182615035349AB@logimail1.LogiXML.local>
User-Agent: Thunderbird 2.0.0.21 (X11/20090623)

Clifton B. Sothoron Jr. wrote:
> Kristian,
> Thanks for replying. I'm using Derby 10.5. There is no derby.log. 

Hi again,

There should be a derby.log. If nothing special has been done, it should 
be in the current working directory of your application / application 
server / shell / whatever when it starts.
Can you try to search for a file called 'derby.log' on your system?

> I'm
> using one JVM using the embedded driver. I've seen it fail while going
> through the resultset and during connect. The error that occurs during
> resultset processing is "Java exception: ':
> org.apache.derby.iapi.error.ShutdownException".  I did not put in any
> shutdown commands. I can reproduce this problem at will.

Don't get me wrong, but that's a good thing :) Means we can get this 
fixed when we figure out what's going on.

> It seems that
> inserts are locking out other attempts to query.  Does closing the
> connection shutdown the database?
>   

No, to shut down the database you have to connect again (either with the 
DriverManager or a DataSource) and specify the shutdown attribute 
(";shutdown=true").

Can you give some more details about other database related software you 
are using, and how the connections are created?
Your database is located on a local disk, right? Keeping the disk on 
something like NFS may cause strange things to happen.
Also, calling Thread.interrupt() is known to cause issues.

It may help us if you set the following system properties when you start 
your application, and report what's written to derby.log;
 -D/derby.infolog.append=true
 -Dderby.stream.error.logSeverityLevel=0
 -Dderby.language.logStatementText=true

(note: if your data is confidential, you may want to avoid logging the 
statement text)

As an alternative, you could also try to use the client driver and see 
what happens there, but this requires that you set up the server of course.


Regards,
-- 
Kristian

/
> Best,
> 		Clif...
>
>
> -----Original Message-----
> From: Kristian Waagan [mailto:Kristian.Waagan@Sun.COM] 
> Sent: Tuesday, July 28, 2009 2:39 AM
> To: Derby Discussion
> Subject: Re: Embedded Derby multi-user
>
> Clifton B. Sothoron Jr. wrote:
>   
>> I'm creating an application which receives various requests to insert,
>>     
>
>   
>> update and query an Embedded Derby database. It works properly except 
>> when one request does a lot of inserts. During this time query 
>> requests are blocked. I get the message edules' not found. --- 
>> "org.apache.derby.impl.jdbc.EmbedSQLException: Database 
>> 'C:\rdScheduler\Schedules' not found." Once the inserts are done then 
>> queries work. I've been rooting around the derby.properties 
>> documentation. It isn't clear to me how to use this file to configure 
>> Derby to allow concurrent access. How is this done?
>>
>>     
>
> Hello Clifton,
>
> Derby allows concurrent access by default, by using multiple connections
>
> to the database. Note that only one JVM can have the database booted at 
> a time. If you need to access the database concurrently from several 
> JVMs, you have to use the network server.
>
> The message you posted indicates that the database you are trying to 
> connect to doesn't exist. Is there anything else printed to your logs, 
> or maybe in the file derby.log?
>
> Just so we're on the same page here;
> - Are you accessing the database with several connections from a single 
> JVM, using the embedded driver?
> - Are you sure you are not trying to boot the same database from 
> different JVMs?
> - Where in your application does the error occur; during connect or 
> during processing?
> - Which version of Derby are you using?
>
> The answers to these questions may bring us closer to finding the 
> problem. Also, please post the stack trace for the error if you have it 
> available.
>
>
> Regards,
>