Re: Derby Embedded losing connection ?
Thanx for you interest. Its version 10.5.3.0 - I will collect more info. No connection pooling by the way. Simple JDBC createConnection. Bernd On Tue, Feb 14, 2012 at 1:24 AM, Bartosz, Jan (NSN - PL/Wroclaw) jan.bart...@nsn.com wrote: Which derby version? Can you provide some stacktrace? .. Regards / Pozdrowienia Jan Bartosz My contact info in Phonebook Click to call me by using Softphone -Original Message- From: ext Bryan Pendleton [mailto:bpendleton.de...@gmail.com] Sent: Tuesday, February 14, 2012 3:19 AM To: Derby Discussion Subject: Re: Derby Embedded losing connection ? get reports (and also felt it our self) that our app simply is losing its connection to the DB. What are the symptoms, exactly? That is, what is it that makes you think you are losing your connection? One thing that occurs to me is a bit of a long-shot: are you using a connection pooling framework of some sort? If so, is it possible that the connection pooling framework is making a mistake and closing a connection inappropriately? thanks, bryan
RE: Derby Embedded losing connection ?
1) First of all - check if you - or somebody in your team does not close connection explicitly;) - f.e.: there is some PMD rule about not closing connection and someone could fix this PMD...;) - was a real case in our project;) 2) In our project there was also problem with loosing connection and reconnecting in derby 10.7.x - don't know how about the previous versions, as we didn't use the DB so heavily. Problem disappeared in latest i.e. 10.8 ver. - where some improvements have been made regarding interruption handlings : * Improved interrupt handling - Interrupting connection threads no longer crashes the Derby engine. http://old.nabble.com/-ANNOUNCE--Apache-Derby-10.8.1.2-released-to315235 46.html#a31523546 Hopefully helps!;) .. Regards / Pozdrowienia Jan Bartosz My contact info in Phonebook Click to call me by using Softphone -Original Message- From: ext bruehlicke [mailto:bruehli...@gmail.com] Sent: Tuesday, February 14, 2012 3:12 PM To: Derby Discussion Subject: Re: Derby Embedded losing connection ? Thanx for you interest. Its version 10.5.3.0 - I will collect more info. No connection pooling by the way. Simple JDBC createConnection. Bernd On Tue, Feb 14, 2012 at 1:24 AM, Bartosz, Jan (NSN - PL/Wroclaw) jan.bart...@nsn.com wrote: Which derby version? Can you provide some stacktrace? .. Regards / Pozdrowienia Jan Bartosz My contact info in Phonebook Click to call me by using Softphone -Original Message- From: ext Bryan Pendleton [mailto:bpendleton.de...@gmail.com] Sent: Tuesday, February 14, 2012 3:19 AM To: Derby Discussion Subject: Re: Derby Embedded losing connection ? get reports (and also felt it our self) that our app simply is losing its connection to the DB. What are the symptoms, exactly? That is, what is it that makes you think you are losing your connection? One thing that occurs to me is a bit of a long-shot: are you using a connection pooling framework of some sort? If so, is it possible that the connection pooling framework is making a mistake and closing a connection inappropriately? thanks, bryan
RE: The selected victim is XID
Brett: thank you for your prompt response.
So, how can I solve this situation? I have one thread which runs a select which
may execute for a minute or longer, and other threads which insert and update
records (more precisely, they batch inserts/updates/deletes and then execute
those batches). How can I prevent these errors from happening and how can I
assure the proper functioning of the application?
Thanks,
Pavel.
From: Bergquist, Brett [mailto:bbergqu...@canoga.com]
Sent: Monday, February 13, 2012 9:01 AM
To: Derby Discussion
Subject: RE: The selected victim is XID
You either had a deadlock as you discovered. You are going to either have to
order your transactions to avoid a deadlock or you can catch the exception and
retry the transaction. Nothing in Derby is going to automatically retry the
insert. Note that the select transaction may have be the one that is
terminated in the future, it depends on what Derby decides is best to allow one
of the transactions to complete.
I do not believe this is anything different than for any other database, at
least not the ones that I have used.
Brett
From: Pavel Bortnovskiy [mailto:pbortnovs...@jefferies.com]
Sent: Monday, February 13, 2012 8:45 AM
To: Derby Discussion (derby-user@db.apache.org)
Subject: The selected victim is XID
Hello:
Today my application threw and exception I haven't seen before:
--REFDATA.INSTYPE in ('M','P','T','G','A') AND
BOOK.ID NOT LIKE 'MD%' AND
BOOK.ID NOT LIKE 'LC%' AND
BOOK.ID NOT LIKE 'P_%'
Granted XID : {9778, X}
Lock : ROW, WINFITS_DB, (6,10742)
Waiting XID : {9778, X} , APP, INSERT INTO A_DB (sec_id,val) VALUES (?,?)
Granted XID : {9749, S}
. The selected victim is XID : 9749.
at org.apache.derby.iapi.error.StandardException.newException(Unknown
Source)
at org.apache.derby.impl.services.locks.Deadlock.buildException(Unknown
Source)
at
org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown
Source)
at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown
Source)
at
org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown Source)
at
org.apache.derby.impl.store.raw.xact.RowLocking2.lockRecordForRead(Unknown
Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknown Source)
at
org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknown Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(Unknown
Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(Unknown
Source)
at
org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(Unknown
Source)
at
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(Unknown
Source)
at org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(Unknown
Source)
at
org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.OnceResultSet.getNextRowCore(Unknown Source)
at
org.apache.derby.exe.acc934c123x0135x7687xc204x1d890d611.g0(Unknown Source)
at
org.apache.derby.exe.acc934c123x0135x7687xc204x1d890d611.e21(Unknown Source)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.doProjection(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowFromSource(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ScrollInsensitiveResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(Unknown
Source)
... 9 more
I did find the article on Debugging Locking Situations:
http://wiki.apache.org/db-derby/LockDebugging
And I did understand the log file that an insert was being made into the same
table on which select was being executed,
But my question is how to prevent these errors from happening? Also, if such an
exception was thrown during an insert,
will the insert be attempted again?
Thanks,
Pavel.
Jefferies archives and monitors outgoing and incoming e-mail. The contents of
this email, including any attachments, are
Re: CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE
Why i aways got an StackOverflowError exception when i try to run CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE() ? ... Caused by: java.lang.StackOverflowError at java.lang.ThreadLocal.get(ThreadLocal.java:125) at java.lang.StringCoding.deref(StringCoding.java:46) at java.lang.StringCoding.encode(StringCoding.java:258) at java.lang.String.getBytes(String.java:946) at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) at java.io.File.exists(File.java:733) at org.apache.derby.impl.store.raw.data.StreamFileContainer.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.store.raw.data.StreamFileContainer.privExists(Unknown Source) at org.apache.derby.impl.store.raw.data.StreamFileContainer.open(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openStreamContainer(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.openStreamContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.dropStreamContainer(Unknown Source) at org.apache.derby.impl.store.raw.xact.Xact.dropStreamContainer(Unknown Source) at org.apache.derby.impl.store.raw.data.DropOnCommit.update(Unknown Source) at java.util.Observable.notifyObservers(Observable.java:142) at org.apache.derby.iapi.store.raw.xact.RawTransaction.notifyObservers(Unknown Source) at org.apache.derby.impl.store.raw.data.DropOnCommit.update(Unknown Source) at java.util.Observable.notifyObservers(Observable.java:142) at org.apache.derby.iapi.store.raw.xact.RawTransaction.notifyObservers(Unknown Source) at org.apache.derby.impl.store.raw.data.DropOnCommit.update(Unknown Source) at java.util.Observable.notifyObservers(Observable.java:142) ... That's clearly a bug in Derby, unfortunately. Can you report it, gathering as much information as possible? http://db.apache.org/derby/DerbyBugGuidelines.html Can you narrow the problem down to a repeatable case that you can include with the bug report? thanks, bryan
Re: Derby Embedded losing connection ?
Thanx for the info - at least I am not feeling alone ;-) ... I will try to trigger the problem and catch all info. Than I will double check our code to see the sequence of closing/reconnecting. After that I will try to upgrade to 10.8.x and see if it goes away. Bernd On Tue, Feb 14, 2012 at 8:42 AM, Bartosz, Jan (NSN - PL/Wroclaw) jan.bart...@nsn.com wrote: 1) First of all - check if you - or somebody in your team does not close connection explicitly;) - f.e.: there is some PMD rule about not closing connection and someone could fix this PMD...;) - was a real case in our project;) 2) In our project there was also problem with loosing connection and reconnecting in derby 10.7.x - don't know how about the previous versions, as we didn't use the DB so heavily. Problem disappeared in latest i.e. 10.8 ver. - where some improvements have been made regarding interruption handlings : * Improved interrupt handling - Interrupting connection threads no longer crashes the Derby engine. http://old.nabble.com/-ANNOUNCE--Apache-Derby-10.8.1.2-released-to315235 46.html#a31523546 Hopefully helps!;) .. Regards / Pozdrowienia Jan Bartosz My contact info in Phonebook Click to call me by using Softphone -Original Message- From: ext bruehlicke [mailto:bruehli...@gmail.com] Sent: Tuesday, February 14, 2012 3:12 PM To: Derby Discussion Subject: Re: Derby Embedded losing connection ? Thanx for you interest. Its version 10.5.3.0 - I will collect more info. No connection pooling by the way. Simple JDBC createConnection. Bernd On Tue, Feb 14, 2012 at 1:24 AM, Bartosz, Jan (NSN - PL/Wroclaw) jan.bart...@nsn.com wrote: Which derby version? Can you provide some stacktrace? .. Regards / Pozdrowienia Jan Bartosz My contact info in Phonebook Click to call me by using Softphone -Original Message- From: ext Bryan Pendleton [mailto:bpendleton.de...@gmail.com] Sent: Tuesday, February 14, 2012 3:19 AM To: Derby Discussion Subject: Re: Derby Embedded losing connection ? get reports (and also felt it our self) that our app simply is losing its connection to the DB. What are the symptoms, exactly? That is, what is it that makes you think you are losing your connection? One thing that occurs to me is a bit of a long-shot: are you using a connection pooling framework of some sort? If so, is it possible that the connection pooling framework is making a mistake and closing a connection inappropriately? thanks, bryan
Re: CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE
Adriano Oliveira wrote: Hi, Could you please help me with compress? Why i aways got an StackOverflowError exception when i try to run CALL SYSCS_UTIL.SYSCS_COMPRESS_TABLE() ? I have about 8 tables (consuming 3Gb of disk space) and compress never got success to compress all of then, I'm using the java application CompressAll listed in this wiki http://wiki.apache.org/db-derby/DatabaseConsistencyCheck Thans, --Adriano Java exception: ': java.lang.StackOverflowError'. Causado por: StackOverflowError java.lang.RuntimeException: Java exception: ': java.lang.StackOverflowError'. at ... removed stack Could you post a full copy of the derby.log containing the error. Sometimes that log has more information, or previous info in it is useful. Best case would be to log a JIRA as Bryan suggests and put all info into it. as a workaround you might try doing one table at a time and committing, then going on to the next table. It should be easy to alter the example java code, let us know if you need help with that. This may also reduce the total amount of disk space needed for the operation. This operation basically creates a new table and indexes and it can not remove the files associated with the old tables and indexes until a commit happens. Also is it at all possible that you are doing other work in the same transaction? The DropOnCommit calls are going to come 1 for each associated object that has a file in derby. This will include 1 for each table, index, constraint, and foreign key. You say you have about 8 tables, do you have an unusual number of objects associated with these tables? Without a repro it is hard to say what is going on. If I had the db first thing I would try to see if the problem still exists if there is not data in the tables, to see if the problem is related to size of tables, or to ddl of the the tables. My first question would be if the drop on commit calls are just too many, or if there is a buggy loop somewhere.
Re: Encrypted db
This solution works... I did not know about ddlutils and I really was missing a product like this. Knut Anders Hatlen-5 wrote: jesusaplsoft je...@aplsoftware.com writes: Is there any way to unencrypt a working encrypted db? As far as I know, the only way to do this currently is to create a new, unencrypted database and manually migrate the data from the encrypted database. Maybe you can use DdlUtils (http://db.apache.org/ddlutils/) to do the migration. There's an example of how to use DdlUtils to export the contents of one Derby database and import them into another Derby database at the Derby web site: http://db.apache.org/derby/integrate/db_ddlutils.html -- Knut Anders -- View this message in context: http://old.nabble.com/Encrypted-db-tp33293118p33324171.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
