Re: Debugging lock timeouts - versuchen01X

2010-03-19 Thread Bryan Pendleton
What I do is I iterate over the db folder and delete all contents, as returned by the java.io API. I delete the db in the tearDown, see it deleted, but then in setup I'm told that it already exists. Do you delete the db folder itself? Or just its contents? Try making sure that the entire db fol

Re: Debugging lock timeouts - versuchen01X

2010-03-19 Thread Gabriele Kahlout
'rm -R myDbDirectory' in *nix' How do you programmatically, from java do that (OS independent)? What I do is I iterate over the db folder and delete all contents, as returned by the java.io API. However, even doing that seems not sufficient. I delete the db in the tearDown, see it deleted, but the

Re: Debugging lock timeouts - versuchen01X

2010-03-17 Thread Gabriele Kahlout
Hello, I shutdown the database in the tearDown method, and all the files are deleted. Yet at the setUp() method when it inits (creates) the database it gives: java.sql.SQLException: Table/View 'EXPRESSIONS' already exists in Schema 'APP', which probably arises due to this checkpoint you are talki

Re: Debugging lock timeouts - versuchen01X

2010-03-03 Thread Kristian Waagan
On 03.03.2010 13:01, Gabriele Kahlout wrote: Okay. In my unit tests I try to delete the previous database completely, so as to run each test from scratch. I close the connection, and then delete all files, however this sticks: seg0, c4b0.dat. Does it have any special meaning? Eitherway, how can

Re: Debugging lock timeouts - versuchen01X

2010-03-03 Thread Gabriele Kahlout
Okay. In my unit tests I try to delete the previous database completely, so as to run each test from scratch. I close the connection, and then delete all files, however this sticks: seg0, c4b0.dat. Does it have any special meaning? Eitherway, how can I get rid of it? I thought con.close() did the

Re: Debugging lock timeouts - versuchen01X

2010-03-03 Thread Knut Anders Hatlen
Gabriele Kahlout writes: > That's interesting. I catch the opportunity to ask, is it possibly to > alias/retrieve the ROWID, of the row? In SQLite that is ROWID, while > reading the Java DB doc, I found no such thing and so tried to > 'simulate' it with RID. However as you pointed above it doesn'

Re: Debugging lock timeouts - versuchen01X

2010-03-03 Thread Gabriele Kahlout
That's interesting. I catch the opportunity to ask, is it possibly to alias/retrieve the ROWID, of the row? In SQLite that is ROWID, while reading the Java DB doc, I found no such thing and so tried to 'simulate' it with RID. However as you pointed above it doesn't alias the ROWID, which I extensiv

Re: Debugging lock timeouts - versuchen01X

2010-03-03 Thread Knut Anders Hatlen
Gabriele Kahlout writes: > Thank you for your answer. It solved it. > > (this is uncommitted code) > private static Connection getConnection(final boolean autoCommit) > throws Exception{ > Connection con = null; > try{ > con = > DriverManager.get

Re: Debugging lock timeouts - versuchen01X

2010-03-03 Thread Gabriele Kahlout
Thank you for your answer. It solved it. (this is uncommitted code) private static Connection getConnection(final boolean autoCommit) throws Exception{ Connection con = null; try{ con = DriverManager.getConnection("jdbc:default:connection");

Re: Debugging lock timeouts - versuchen01X

2010-03-02 Thread Knut Anders Hatlen
Gabriele Kahlout writes: > java.sql.SQLException: The exception 'java.sql.SQLException: A lock > could not be obtained within the time requested. The lockTable dump > is: Hi Gabriele, Just a guess, but could it be that the stored procedure you call from the trigger obtains a new connection to

Re: Debugging lock timeouts - versuchen01X

2010-03-01 Thread Gabriele Kahlout
hmm..I thought of it as the closest implementation to the doc. How else would you write it? Indeed, the derby.properties file is almost empty. 2010/3/1, Rick Hillegas : > Hi Gabriele, > > Have you checked the contents of derby.properties? The following code > looks a little odd. It looks as thoug

Re: Debugging lock timeouts - versuchen01X

2010-03-01 Thread Rick Hillegas
Hi Gabriele, Have you checked the contents of derby.properties? The following code looks a little odd. It looks as though you are writing the Properties object to disk before you have actually set the properties. Regards, -Rick Gabriele Kahlout wrote: I've added the following code to trace:

Debugging lock timeouts - versuchen01X

2010-03-01 Thread Gabriele Kahlout
I've added the following code to trace: final Properties prop = new java.util.Properties(); prop.save(new FileOutputStream(new File("derby.properties")), "derby.properties"); prop.setProperty("derby.locks.deadlockTrace", "true");