Re: Conglomerate could not be created?

2012-06-05 Thread John English

On 04/06/2012 19:57, Katherine Marsden wrote:

On 6/4/2012 9:29 AM, John English wrote:

I'm on 10.8, and I only have about a dozen matching rows at the
moment. No stack trace that goes further than my own code; all I have
is stuff like this:

Check the derby.log for the error and full stack trace. If the derby.log
doesn't show the error, try setting derby.infolog.append=true in the
derby.properties or system property temporarily, so you don't lose the
log when the database reboots.


The problem was that the original exception info was being masked by my
rethrowing it with the parameter information. Full version info from the
log: Apache Derby - 10.8.1.2 - (1095077)

Here's an example of a failed query and parameters:

INSERT INTO resource_usage (resid,itemid,itemtype) (SELECT resid,?,? 
FROM resource_usage WHERE itemid=? AND itemtype=? AND resid NOT IN 
(SELECT resid FROM resource_usage WHERE itemid=? AND itemtype=?))

Query parameters: 1='24' 2='final' 3='18' 4='temp' 5='24' 6='final'):

Here's the resulting stack trace from the point just before I rethrow:

java.sql.SQLException: Conglomerate could not be created.
  at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown 
Source)

  at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
  at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown 
Source)
  at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown 
Source)
  at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown 
Source)
  at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown 
Source)
  at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown 
Source)
  at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown 
Source)
  at 
org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown 
Source)

  at utils.DataManager.dbInsert(DataManager.java:1056)
  at actions.EditAction.copyResources(EditAction.java:1638)
  at actions.EditAction.doRelease(EditAction.java:1171)
  at actions.EditAction.processUpdates(EditAction.java:537)
  at servlets.BaseServlet.doGet(BaseServlet.java:190)
  at servlets.BaseServlet.doPost(BaseServlet.java:304)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
  [... snip ...]
  at java.lang.Thread.run(Unknown Source)
Caused by: java.sql.SQLException: Conglomerate could not be created.
  at 
org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown 
Source)
  at 
org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown 
Source)

  ... 45 more
Caused by: ERROR XSCH4: Conglomerate could not be created.
  at org.apache.derby.iapi.error.StandardException.newException(Unknown 
Source)

  at org.apache.derby.impl.store.access.heap.Heap.create(Unknown Source)
  at 
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.createConglomerate(Unknown 
Source)
  at 
org.apache.derby.impl.store.access.RAMTransaction.createConglomerate(Unknown 
Source)
  at 
org.apache.derby.impl.sql.execute.TemporaryRowHolderImpl.insert(Unknown 
Source)
  at 
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown 
Source)

  at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source)
  at 
org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
Source)
  at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
Source)

  ... 39 more


--
 John English


SYSCS_DIAG.TRANSACTION_TABLE

2012-06-05 Thread Pavel Bortnovskiy
Hello, all:

While trying to debug an anomaly within my app, I wanted to see all the active 
transactions within Derby (in-memory mode).
However, accessing SYSCS_DIAG.TRANSACTION_TABLE  table didn't prove very 
useful, as it is not possible to identify what statements those transactions 
execute, with the exception of one - the select from that table itself.

[cid:image001.png@01CD4306.49B6BD70]

Is there any other way to get more diag information?
Can I find the statements' text by XIDs elsewhere?

Thanks,
Pavel.
Jefferies archives and monitors outgoing and incoming e-mail. The contents of 
this email, including any attachments, are confidential to the ordinary user of 
the email address to which it was addressed. If you are not the addressee of 
this email you may not copy, forward, disclose or otherwise use it or any part 
of it in any form whatsoever. This email may be produced at the request of 
regulators or in connection with civil litigation. Jefferies accepts no 
liability for any errors or omissions arising as a result of transmission. Use 
by other than intended recipients is prohibited. In the United Kingdom, 
Jefferies operates as Jefferies International Limited; registered in England: 
no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London 
EC4V 3BJ. Jefferies International Limited is authorised and regulated by the 
Financial Services Authority.
inline: image001.png

Re: Conglomerate could not be created?

2012-06-05 Thread Dag H. Wanvik

Looks like a bug to me. The error XSCH4 Conglomerate could not be
created isn't being tested for in the Derby tests as far as I can
see. I also searched the bug tracker
(https://issues.apache.org/jira/browse/DERBY) in vain for this
particular error.

Looking in the code where the error is reported in the source code, it
looks like it shouldn't happen. Could you post a JIRA bug report for
this error, please?  It you are able to make a stand-alone repro that
will increase your chances of having it fixed.

Thanks,
Dag



Re: SYSCS_DIAG.TRANSACTION_TABLE

2012-06-05 Thread Rick Hillegas

Hi Pavel,

Note that the SQL_TEXT column will be null for any transaction which is 
not currently executing a statement. If you turn on statement logging 
(-Dderby.language.logStatementText=true), then your statement text will 
be logged to derby.log. You can use the syscs_diag.error_log_reader() 
vti to see what statements were run in each transaction. So the 
following sequence of calls may give you a lot of useful information:


select * from syscs_diag.transaction_table;

select * from table (syscs_diag.error_log_reader()) as t1;

Hope this helps,
-Rick

On 6/5/12 7:30 AM, Pavel Bortnovskiy wrote:


Hello, all:

While trying to debug an anomaly within my app, I wanted to see all 
the active transactions within Derby (in-memory mode).


However, accessing SYSCS_DIAG.TRANSACTION_TABLE table didn’t prove 
very useful, as it is not possible to identify what statements those 
transactions execute, with the exception of one – the select from that 
table itself.


Is there any other way to get more diag information?

Can I find the statements’ text by XIDs elsewhere?

Thanks,

Pavel.


Jefferies archives and monitors outgoing and incoming
e-mail. The contents of this email, including any
attachments, are confidential to the ordinary user of the
email address to which it was addressed. If you are not
the addressee of this email you may not copy, forward,
disclose or otherwise use it or any part of it in any form
whatsoever. This email may be produced at the request of
regulators or in connection with civil litigation.
Jefferies accepts no liability for any errors or omissions
arising as a result of transmission. Use by other than
intended recipients is prohibited. In the United Kingdom,
Jefferies operates as Jefferies International Limited;
registered in England: no. 1978621; registered office:
Vintners Place, 68 Upper Thames Street, London EC4V 3BJ.
Jefferies International Limited is authorised and
regulated by the Financial Services Authority.






RE: SYSCS_DIAG.TRANSACTION_TABLE

2012-06-05 Thread Pavel Bortnovskiy
Excellent! Thank you, Rick for your prompt response.

-Original Message-
From: Rick Hillegas [mailto:rick.hille...@oracle.com]
Sent: Tuesday, June 05, 2012 12:30 PM
To: derby-user@db.apache.org
Subject: Re: SYSCS_DIAG.TRANSACTION_TABLE

Hi Pavel,

Note that the SQL_TEXT column will be null for any transaction which is not 
currently executing a statement. If you turn on statement logging 
(-Dderby.language.logStatementText=true), then your statement text will be 
logged to derby.log. You can use the syscs_diag.error_log_reader() vti to see 
what statements were run in each transaction. So the following sequence of 
calls may give you a lot of useful information:

select * from syscs_diag.transaction_table;

select * from table (syscs_diag.error_log_reader()) as t1;

Hope this helps,
-Rick

On 6/5/12 7:30 AM, Pavel Bortnovskiy wrote:

 Hello, all:

 While trying to debug an anomaly within my app, I wanted to see all
 the active transactions within Derby (in-memory mode).

 However, accessing SYSCS_DIAG.TRANSACTION_TABLE table didn't prove
 very useful, as it is not possible to identify what statements those
 transactions execute, with the exception of one - the select from that
 table itself.

 Is there any other way to get more diag information?

 Can I find the statements' text by XIDs elsewhere?

 Thanks,

 Pavel.


 Jefferies archives and monitors outgoing and incoming
 e-mail. The contents of this email, including any
 attachments, are confidential to the ordinary user of the
 email address to which it was addressed. If you are not
 the addressee of this email you may not copy, forward,
 disclose or otherwise use it or any part of it in any form
 whatsoever. This email may be produced at the request of
 regulators or in connection with civil litigation.
 Jefferies accepts no liability for any errors or omissions
 arising as a result of transmission. Use by other than
 intended recipients is prohibited. In the United Kingdom,
 Jefferies operates as Jefferies International Limited;
 registered in England: no. 1978621; registered office:
 Vintners Place, 68 Upper Thames Street, London EC4V 3BJ.
 Jefferies International Limited is authorised and
 regulated by the Financial Services Authority.



Jefferies archives and monitors outgoing and incoming e-mail. The contents of 
this email, including any attachments, are confidential to the ordinary user of 
the email address to which it was addressed. If you are not the addressee of 
this email you may not copy, forward, disclose or otherwise use it or any part 
of it in any form whatsoever. This email may be produced at the request of 
regulators or in connection with civil litigation. Jefferies accepts no 
liability for any errors or omissions arising as a result of transmission. Use 
by other than intended recipients is prohibited. In the United Kingdom, 
Jefferies operates as Jefferies International Limited; registered in England: 
no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London 
EC4V 3BJ. Jefferies International Limited is authorised and regulated by the 
Financial Services Authority.