[jira] Updated: (DERBY-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] Oyvind Bakksjo updated DERBY-297: - Attachment: derbyhatlogo-lettersaligned.png Maybe someone who's more skilled with graphics than I am can take the hat idea, place all the characters on the same baseline and still make it look like a hat? My attachment doesn't look much like a hat, it just illustrates what I mean. Submit an entry for the Derby logo contest by uploading it to this issue Key: DERBY-297 URL: http://issues.apache.org/jira/browse/DERBY-297 Project: Derby Type: Task Components: Web Site Reporter: Jean T. Anderson Assignee: Jean T. Anderson Priority: Minor Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, andrew-derbyknight1.jpg, andrew-derbyknight2.jpg, derby hat.jpeg, derby4.jpg, derbyhatlogo-lettersaligned.png On May 3 Susan Cline posted a note to kick start the Derby logo contest: http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] If you have a logo to submit, please attach it to this issue. (See http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] for the suggestion on using Jira to manage logo submissions.) Discussions about the logo contest are at [EMAIL PROTECTED] To subscribe to that list, send an empty email to [EMAIL PROTECTED] More information about the Derby mail lists is at http://db.apache.org/derby/derby_mail.html . CURRENT IMAGES File : Submitter derby4.jpg : Andrew Kachalo andrew-derbyhat1.jpg : Andrew McIntyre andrew-derbyhat2.jpg : Andrew McIntyre andrew-derbyknight1.jpg : Andrew McIntyre andrew-derbyknight2.jpg : Andrew McIntyre derby_hat.jpeg: David Van Couvering -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-704) Large page cache kills initial performance
[ http://issues.apache.org/jira/browse/DERBY-704?page=all ] Bernt M. Johnsen resolved DERBY-704: Resolution: Fixed Large page cache kills initial performance -- Key: DERBY-704 URL: http://issues.apache.org/jira/browse/DERBY-704 Project: Derby Type: Bug Components: Services, Performance Versions: 10.1.2.2, 10.1.3.0, 10.2.0.0, 10.1.2.1, 10.1.2.0, 10.1.1.2, 10.1.1.1, 10.1.1.0 Environment: All platforms Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.2.0.0 Attachments: DERBY-704-extra-comments.diff, DERBY-704.diff, cpu-usage.png, derbyall_report.txt, throughput.png When the page cache is large the performance gets lower as the page cache is being filled. As soon as the page cache is filled, the throughput increases. In the period with low performance, the CPU usage is high, and when the performance increases the CPU usage is lower. This behaviour is caused by the algorithm for finding free slots in the page cache. If there are invalid pages in the page cache, it will be scanned to find one of those pages. However, when multiple clients access the database, the invalid pages are often already taken. This means that the entire page cache will be scanned, but no free invalid page is found. Since the scan of the page cache is synchronized on the cache manager, all other threads that want to access the page cache have to wait. When the page cache is large, this will kill the performance. When the page cache is full, this is not a problem, as there will be no invalid pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-704) Large page cache kills initial performance
[ http://issues.apache.org/jira/browse/DERBY-704?page=all ] Knut Anders Hatlen closed DERBY-704: Fixed in revision 344270. Extra comments put into the code in revision 345215. Large page cache kills initial performance -- Key: DERBY-704 URL: http://issues.apache.org/jira/browse/DERBY-704 Project: Derby Type: Bug Components: Services, Performance Versions: 10.1.2.2, 10.1.3.0, 10.2.0.0, 10.1.2.1, 10.1.2.0, 10.1.1.2, 10.1.1.1, 10.1.1.0 Environment: All platforms Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.2.0.0 Attachments: DERBY-704-extra-comments.diff, DERBY-704.diff, cpu-usage.png, derbyall_report.txt, throughput.png When the page cache is large the performance gets lower as the page cache is being filled. As soon as the page cache is filled, the throughput increases. In the period with low performance, the CPU usage is high, and when the performance increases the CPU usage is lower. This behaviour is caused by the algorithm for finding free slots in the page cache. If there are invalid pages in the page cache, it will be scanned to find one of those pages. However, when multiple clients access the database, the invalid pages are often already taken. This means that the entire page cache will be scanned, but no free invalid page is found. Since the scan of the page cache is synchronized on the cache manager, all other threads that want to access the page cache have to wait. When the page cache is large, this will kill the performance. When the page cache is full, this is not a problem, as there will be no invalid pages. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-713) CLONE - Query optimizer should not make poor choices when optimizing IN and WHERE clauses
CLONE - Query optimizer should not make poor choices when optimizing IN and
WHERE clauses
-
Key: DERBY-713
URL: http://issues.apache.org/jira/browse/DERBY-713
Project: Derby
Type: Improvement
Components: SQL
Versions: 10.0.2.0
Environment: all
Reporter: Daniel James Neades
Consider a simple case of -
A table tbl has 1 rows, there is a primary key index on i1
and the query in question is
select * from tbl where i1 in (-1,10)
derby does a table scan of the entire table even though the IN list has only
two values and the comparison is on a field that has an index.
Briefly looking at the code, it seems like we insert a between and use the IN
list to get the start and stop values for the scan. Thus the range of the
values in the IN list here plays an important role.
Thus if the query was changed to select * from tbl where i1 in (-1, 1), an
index scan would be chosen.
It would be nice if we could do something clever in this case where there is
clearly an index on the field and the number of values in the IN list is known.
Maybe use the rowcount estimate and the IN list size to do some optimizations.
- consider the length of the IN list to do searches on the table. ie use the
IN list values to do index key searches on the table,
-or try to convert it to a join. Use the IN list values to create a temporary
table and do a join. It is most likely that the optimizer will choose the table
with IN list here as the outer table in the join and thus will do key
searches on the larger table.
---
some query plans that I logged using derby.language.logQueryPlan=true for some
similar queries:
Table has ascending values from 0 - for i1. primary key index on i1.
GMT Thread[UT0,5,main] (XID = 19941), (SESSIONID = 0), select * from scanfixed
where i1 in (-1,,9998,9997,9996,9995,9994,9993,9992,9991,9990) ***
Project-Restrict ResultSet (2):
Number of opens = 1
Rows seen = 1
Rows filtered = 9990
restriction = true
projection = false
constructor time (milliseconds) = 0
open time (milliseconds) = 0
next time (milliseconds) = 0
close time (milliseconds) = 0
restriction time (milliseconds) = 0
projection time (milliseconds) = 0
optimizer estimated row count: 750.38
optimizer estimated cost: 8579.46
Source result set:
Table Scan ResultSet for SCANFIXED at read committed isolation level
using instantaneous share row locking chosen by the optimizer
Number of opens = 1
Rows seen = 1
Rows filtered = 0
Fetch Size = 16
constructor time (milliseconds) = 0
open time (milliseconds) = 0
next time (milliseconds) = 0
close time (milliseconds) = 0
next time in milliseconds/row = 0
scan information:
Bit set of columns fetched=All
Number of columns fetched=9
Number of pages visited=417
Number of rows qualified=1
Number of rows visited=1
Scan type=heap
start position:
nullstop position:
nullqualifiers:
Column[0][0] Id: 0
Operator: =
Ordered nulls: false
Unknown return value: false
Negate comparison result: false
Column[0][1] Id: 0
Operator:
Ordered nulls: false
Unknown return value: true
Negate comparison result: true
optimizer estimated row count: 750.38
optimizer estimated cost: 8579.46
---
l
2004-10-14 18:59:47.577 GMT Thread[UT0,5,main] (XID = 19216), (SESSIONID = 0),
select * from scanfixed where i1 in
(,9998,9997,9996,9995,9994,9993,9992,9991,9990) *** Project-Restrict
ResultSet (3):
Number of opens = 1
Rows seen = 10
Rows filtered = 0
restriction = true
projection = true
constructor time (milliseconds) = 0
open time (milliseconds) = 0
next time (milliseconds) = 0
close time (milliseconds) = 0
restriction time (milliseconds) = 0
projection time (milliseconds) = 0
optimizer estimated row count:4.80
optimizer estimated cost: 39.53
Source result set:
Index Row to Base Row ResultSet for SCANFIXED:
Number of opens = 1
Rows seen = 10
Columns accessed from heap = {0, 1, 2, 3, 4, 5, 6, 7, 8}
constructor time (milliseconds) = 0
open time (milliseconds) = 0
next time (milliseconds) = 0
close time (milliseconds) = 0
optimizer
[jira] Commented: (DERBY-713) CLONE - Query optimizer should not make poor choices when optimizing IN and WHERE clauses
[ http://issues.apache.org/jira/browse/DERBY-713?page=comments#action_12357867 ] Daniel James Neades commented on DERBY-713: --- Creating a clone probably wasn't the right thing to do, but given the extra information now added to DERBY-47, it should be of type defect and not merely an improvement. My apologies if I've done the wrong thing, but perhaps a JIRA admin can sort this out and change DERBY-47's type and summary? The extra comments on DERBY-47 describe how the query optimizer is making very poor choices when dealing with IN clauses with multiple terms (and equivalent WHERE thing=x OR thing=y OR thing=z expressions). This makes Derby performance very poor, even for some simple queries. In addition, the optimizer seems to use inappropriate indexes in certain circumstances (again, described in comments added to DERBY-47), meaning that performance can degrade significantly degrade, merely by the presence of an additional index on a table. This means adding indexes to a table in an attempt to improve one query can unexpectedly degrade the performance of other queries. I believe that this should be considered a major defect. CLONE - Query optimizer should not make poor choices when optimizing IN and WHERE clauses - Key: DERBY-713 URL: http://issues.apache.org/jira/browse/DERBY-713 Project: Derby Type: Improvement Components: SQL Versions: 10.0.2.0 Environment: all Reporter: Daniel James Neades Consider a simple case of - A table tbl has 1 rows, there is a primary key index on i1 and the query in question is select * from tbl where i1 in (-1,10) derby does a table scan of the entire table even though the IN list has only two values and the comparison is on a field that has an index. Briefly looking at the code, it seems like we insert a between and use the IN list to get the start and stop values for the scan. Thus the range of the values in the IN list here plays an important role. Thus if the query was changed to select * from tbl where i1 in (-1, 1), an index scan would be chosen. It would be nice if we could do something clever in this case where there is clearly an index on the field and the number of values in the IN list is known. Maybe use the rowcount estimate and the IN list size to do some optimizations. - consider the length of the IN list to do searches on the table. ie use the IN list values to do index key searches on the table, -or try to convert it to a join. Use the IN list values to create a temporary table and do a join. It is most likely that the optimizer will choose the table with IN list here as the outer table in the join and thus will do key searches on the larger table. --- some query plans that I logged using derby.language.logQueryPlan=true for some similar queries: Table has ascending values from 0 - for i1. primary key index on i1. GMT Thread[UT0,5,main] (XID = 19941), (SESSIONID = 0), select * from scanfixed where i1 in (-1,,9998,9997,9996,9995,9994,9993,9992,9991,9990) *** Project-Restrict ResultSet (2): Number of opens = 1 Rows seen = 1 Rows filtered = 9990 restriction = true projection = false constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 restriction time (milliseconds) = 0 projection time (milliseconds) = 0 optimizer estimated row count: 750.38 optimizer estimated cost: 8579.46 Source result set: Table Scan ResultSet for SCANFIXED at read committed isolation level using instantaneous share row locking chosen by the optimizer Number of opens = 1 Rows seen = 1 Rows filtered = 0 Fetch Size = 16 constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 next time in milliseconds/row = 0 scan information: Bit set of columns fetched=All Number of columns fetched=9 Number of pages visited=417 Number of rows qualified=1 Number of rows visited=1 Scan type=heap start position: null stop position: null qualifiers: Column[0][0] Id: 0 Operator: = Ordered nulls: false Unknown return value: false Negate comparison result: false Column[0][1] Id: 0 Operator: Ordered nulls: false Unknown return value: true Negate comparison result: true optimizer estimated row count: 750.38 optimizer estimated cost: 8579.46
[jira] Resolved: (DERBY-707) providing RowLocation for deleted+purged row to GenericConglomerateController causes nullpointerexception
[ http://issues.apache.org/jira/browse/DERBY-707?page=all ]
Bernt M. Johnsen resolved DERBY-707:
Fix Version: 10.2.0.0
Resolution: Fixed
providing RowLocation for deleted+purged row to GenericConglomerateController
causes nullpointerexception
-
Key: DERBY-707
URL: http://issues.apache.org/jira/browse/DERBY-707
Project: Derby
Type: Bug
Components: Store
Environment: Java 1.4
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Minor
Fix For: 10.2.0.0
Attachments: DERBY-707.diff, DERBY-707.stat
To provide scrollable updatable resultsets, we will store the RowLocation for
every row in the ResultSet in a temporary table (backingstore hashtable).
The RowLocation is used to reposition the cursor before an update.
The problem is when the row for the RowLocation has been deleted and purged
by another transaction. The update will then fail with a
NullPointerException in GenericConglomerateController.replace(..):
java.lang.NullPointerException
at
org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:465)
at
org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:516)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:577)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:276)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368)
at
org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3256)
It fails when checking if the row has been deleted (not purged) , because
pos.current_page is null:
if (pos.current_page.isDeletedAtSlot(pos.current_slot))
{
ret_val = false;
}
The proposed fix is to use the return value from open_conglom.latchPage(..).
If it returns false, the RowLocation is invalid (deleted+purged).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-707) providing RowLocation for deleted+purged row to GenericConglomerateController causes nullpointerexception
[ http://issues.apache.org/jira/browse/DERBY-707?page=all ]
Andreas Korneliussen closed DERBY-707:
--
Fix has been committed.
providing RowLocation for deleted+purged row to GenericConglomerateController
causes nullpointerexception
-
Key: DERBY-707
URL: http://issues.apache.org/jira/browse/DERBY-707
Project: Derby
Type: Bug
Components: Store
Environment: Java 1.4
Reporter: Andreas Korneliussen
Assignee: Andreas Korneliussen
Priority: Minor
Fix For: 10.2.0.0
Attachments: DERBY-707.diff, DERBY-707.stat
To provide scrollable updatable resultsets, we will store the RowLocation for
every row in the ResultSet in a temporary table (backingstore hashtable).
The RowLocation is used to reposition the cursor before an update.
The problem is when the row for the RowLocation has been deleted and purged
by another transaction. The update will then fail with a
NullPointerException in GenericConglomerateController.replace(..):
java.lang.NullPointerException
at
org.apache.derby.impl.store.access.conglomerate.GenericConglomerateController.replace(GenericConglomerateController.java:465)
at
org.apache.derby.impl.sql.execute.RowChangerImpl.updateRow(RowChangerImpl.java:516)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(UpdateResultSet.java:577)
at
org.apache.derby.impl.sql.execute.UpdateResultSet.open(UpdateResultSet.java:276)
at
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:368)
at
org.apache.derby.impl.jdbc.EmbedResultSet.updateRow(EmbedResultSet.java:3256)
It fails when checking if the row has been deleted (not purged) , because
pos.current_page is null:
if (pos.current_page.isDeletedAtSlot(pos.current_slot))
{
ret_val = false;
}
The proposed fix is to use the return value from open_conglom.latchPage(..).
If it returns false, the RowLocation is invalid (deleted+purged).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: RowLocation lifetime
MM == Mike Matrigali [EMAIL PROTECTED] writes: MM Øystein Grøvlen wrote: MM == Mike Matrigali [EMAIL PROTECTED] writes: MM It is only stable while some sort of stable table intent lock is held. MM Rows can move during a compress table operation. I understand, when a record is moved to another page, its RecordId will change. Is this the only case where a RecordId will change? If yes, I would think one could solve the problem for insensitive result sets by invalidating open result sets when an underlying table is compressed. Some questions to how compression works: - Will RecordIds ever be reused or will the sequence number continue to increase? MM Derby now supports 2 different compression techniques, basically one MM offline and one online. MM SYSCS_UTIL.SYSCS_COMPRESS_TABLE() basically copies all rows from one MM table to another, so recordId's may be reused. This requires table MM level locking and so is effectively offline. Do not the new version of the table get a new container key? If yes, I would think that recordId's are not reused since container key is part of the record id. MM SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE() moves records within the MM same table, and will not reuse RecordId's, but a given record can MM definitely change RecordId. This requires row locks MM for purged/moved rows for most of it's work. Giving back space to MM OS requires short time table level lock. Good, I was not aware that there was an online version of compress. - How do you ensure that the old RecordIds are not encountered during recovery? Does the compression include a checkpoint? MM Neither really does anything special to stop old recordId's from MM being encountered during recovery. With offline redo recovery of MM old table is basically a drop table so either the table is there MM and we drop it again, or the table is already dropped and we do MM nothing. In online it is the normal case of redo or a record delete MM or a record purge, in either case redo will either see a version of MM the page where it can redo the delete or purge or it will see from MM the version of the page that there is no work to do. -- Øystein
Use of Apache feather in logo
Does anyone know if there is a reason we can't directly use the Apache feather in our logo? Thanks, David
Re: [jira] Commented: (DERBY-280) Wrong result from select when aliasing to same name as used in group by
Hi Satheesh, I fixed the npe you spotted and attached the updated patch to the JIRA issue. This is ready for you to commit when you have a moment. Thanks, -Rick
[jira] Updated: (DERBY-297) Submit an entry for the Derby logo contest by uploading it to this issue
[ http://issues.apache.org/jira/browse/DERBY-297?page=all ] David Van Couvering updated DERBY-297: -- Attachment: (was: derby hat.jpeg) Submit an entry for the Derby logo contest by uploading it to this issue Key: DERBY-297 URL: http://issues.apache.org/jira/browse/DERBY-297 Project: Derby Type: Task Components: Web Site Reporter: Jean T. Anderson Assignee: Jean T. Anderson Priority: Minor Attachments: andrew-derbyhat1.jpg, andrew-derbyhat2.jpg, andrew-derbyknight1.jpg, andrew-derbyknight2.jpg, derby4.jpg, derbyhatlogo-lettersaligned.png On May 3 Susan Cline posted a note to kick start the Derby logo contest: http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] If you have a logo to submit, please attach it to this issue. (See http://mail-archives.apache.org/mod_mbox/db-derby-user/200505.mbox/[EMAIL PROTECTED] for the suggestion on using Jira to manage logo submissions.) Discussions about the logo contest are at [EMAIL PROTECTED] To subscribe to that list, send an empty email to [EMAIL PROTECTED] More information about the Derby mail lists is at http://db.apache.org/derby/derby_mail.html . CURRENT IMAGES File : Submitter derby4.jpg : Andrew Kachalo andrew-derbyhat1.jpg : Andrew McIntyre andrew-derbyhat2.jpg : Andrew McIntyre andrew-derbyknight1.jpg : Andrew McIntyre andrew-derbyknight2.jpg : Andrew McIntyre derby_hat.jpeg: David Van Couvering -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Use of Apache feather in logo
David Van Couvering wrote: Does anyone know if there is a reason we can't directly use the Apache feather in our logo? When Derby was under incubation my understanding was we could use the Apache logo, but it might be wise to ask legal-discuss. --I haven't seen this topic raised visibly. Since you're a committer, do you want to raise it, David? If you don't, I'll volunteer. -jean
Cannot make web site changes visible: svn: Can't open file '.svn/lock': Permission denied
The web page at http://db.apache.org/derby/papers/derby_web.html#7.+Make+web+site+changes+visible says the following: -- A Derby committer can make web site changes visible as follows: ssh -l your_apache_login people.apache.org cd /www/db.apache.org/derby svn update -- I tried: -bash-2.05b$ cd /www/db.apache.org/derby -bash-2.05b$ svn update svn: Can't open file '.svn/lock': Permission denied -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Cannot make web site changes visible: svn: Can't open file '.svn/lock': Permission denied
[EMAIL PROTECTED] wrote: The web page at http://db.apache.org/derby/papers/derby_web.html#7.+Make+web+site+changes+visible says the following: -- A Derby committer can make web site changes visible as follows: ssh -l your_apache_login people.apache.org cd /www/db.apache.org/derby svn update -- I tried: -bash-2.05b$ cd /www/db.apache.org/derby -bash-2.05b$ svn update svn: Can't open file '.svn/lock': Permission denied What groups are you in, Oyvind? You need to be in 'db' -- are you? -bash-2.05b$ whoami jta -bash-2.05b$ groups jta apcvs db incubator -jean
Re: New Enhancement Request
Vishwani Sodhi wrote: Hi, My name is Vishwani Sodhi, I work for Software Development/Tools Department in Lenovo. I have the following request for a feature to be added in Cloudscape: * I would like to be able to specify an alternate default port number for the client driver to use in establishing connections. Does the javax.sql.DataSource api help out here, use DataSources to get connections anc configure the DataSource (org.apache.derby.jdbc.ClientDataSource), set its portNumber property, with the correct port number? Please let me know if this is something that can be done and a time frame of when it can be fulfilled. Just a reminder, Derby is a community open source project, people work on what 'scratches their itch'. There is not a Derby team responsible for adding features or fixing bugs entered by users. People in the community, and that means anyone, address issues either out of their own needs, or because they want to help the community as a whole. As Satheesh said, the only real way to guarantee a feature is added is to add it yourself. Folks on the derby-dev list will help out with implementation details and if the feature is appropriate for Derby. Dan.
Re: Cannot make web site changes visible: svn: Can't open file '.svn/lock': Permission denied
Jean T. Anderson wrote: What groups are you in, Oyvind? You need to be in 'db' -- are you? I thought it might be a group thing. -bash-2.05b$ groups bakksjo apcvs incubator Exactly. -- Oyvind Bakksjo Sun Microsystems, Database Technology Group Trondheim, Norway http://weblogs.java.net/blog/bakksjo/
Re: Cannot make web site changes visible: svn: Can't open file '.svn/lock': Permission denied
[EMAIL PROTECTED] wrote: Jean T. Anderson wrote: What groups are you in, Oyvind? You need to be in 'db' -- are you? I thought it might be a group thing. -bash-2.05b$ groups bakksjo apcvs incubator Exactly. OK, Oyvind, I'll ask the DB PMC to add you to the 'db' group. In the meantime, I did an 'svn up' so your changes should be visible in an hour or so. --And thank you for making those changes. -jean
Re: Use of Apache feather in logo
I'll raise it with legal-discuss. Thanks, Jean. David Jean T. Anderson wrote: David Van Couvering wrote: Does anyone know if there is a reason we can't directly use the Apache feather in our logo? When Derby was under incubation my understanding was we could use the Apache logo, but it might be wise to ask legal-discuss. --I haven't seen this topic raised visibly. Since you're a committer, do you want to raise it, David? If you don't, I'll volunteer. -jean begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
[jira] Updated: (DERBY-556) NetworkServer does not set thread context classloader
[ http://issues.apache.org/jira/browse/DERBY-556?page=all ] Jeremy Boynes updated DERBY-556: Attachment: Derby556.java Java program to illustrate the problem. NetworkServer does not set thread context classloader - Key: DERBY-556 URL: http://issues.apache.org/jira/browse/DERBY-556 Project: Derby Type: Bug Components: Network Server Versions: 10.1.1.0 Reporter: Jeremy Boynes Assignee: Rick Hillegas Attachments: Derby556.java, MathUtils.jar, ServerStarter.java, z.sql, zz.sql The NetworkServer does not set the thread context classloader which is used to load the implementations of stored procedures. As a result, procedure implementations must be present in the classpath of the engine itself; this differs from embedded mode where classes may be located in the application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
I am looking at reviewing/committing this patch. Suresh Thalamati (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-239?page=all ] Suresh Thalamati updated DERBY-239: --- Attachment: onlinebackup_3.diff This patch adds code to support real-time online backup with unlogged operations. A consistent backup can not be made if there are pending transactions with unlogged operations or if unlogged operations occur when backup is in progress. Because container files can be copied to the backup before the transaction is committed and the data pages are flushed as part of the commit. As there is no transaction log for unlogged operations, while restoring from the backup database can not be restored to a consistent state. To make a consistent online backup in this scenario, this patch: 1) blocks online backup until all the transactions with unlogged operation are committed/aborted. 2) implicitly converts all unlogged operations to logged mode for the duration of the online backup, if they are started when backup is in progress. This patch also adds a test to test the online backup in parallel with some DML, DDL and unlogged operations. TESTS : derbyall test suite passed on Windows XP/JDK142 It would be great if some can review and commit this patch. svn stat: M java\engine\org\apache\derby\impl\store\raw\xact\Xact.java M java\engine\org\apache\derby\impl\store\raw\xact\XactFactory.java M java\engine\org\apache\derby\impl\store\raw\RawStore.java M java\engine\org\apache\derby\impl\store\raw\data\BaseDataFileFactory.java M java\engine\org\apache\derby\iapi\store\raw\xact\RawTransaction.java M java\engine\org\apache\derby\iapi\store\raw\xact\TransactionFactory.java M java\testing\org\apache\derbyTesting\functionTests\tests\storetests\st_1.sql A java\testing\org\apache\derbyTesting\functionTests\tests\store\OnlineBackupTest1_app.properties A java\testing\org\apache\derbyTesting\functionTests\tests\store\OnlineBackup.java M java\testing\org\apache\derbyTesting\functionTests\tests\store\copyfiles.ant A java\testing\org\apache\derbyTesting\functionTests\tests\store\OnlineBackupTest1.java M java\testing\org\apache\derbyTesting\functionTests\master\st_1.out A java\testing\org\apache\derbyTesting\functionTests\master\OnlineBackupTest1.out M java\testing\org\apache\derbyTesting\functionTests\suites\storemore.runall Need a online backup feature that does not block update operations when online backup is in progress. Key: DERBY-239 URL: http://issues.apache.org/jira/browse/DERBY-239 Project: Derby Type: New Feature Components: Store Versions: 10.1.1.0 Reporter: Suresh Thalamati Assignee: Suresh Thalamati Attachments: onlinebackup.html, onlinebackup_1.diff, onlinebackup_2.diff, onlinebackup_3.diff Currently Derby allows users to perfoms online backups using SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure, but while the backup is in progress, update operations are temporarily blocked, but read operations can still proceed. Blocking update operations can be real issue specifically in client server environments, because user requests will be blocked for a long time if a backup is in the progress on the server.
[jira] Commented: (DERBY-280) Wrong result from select when aliasing to same name as used in group by
[ http://issues.apache.org/jira/browse/DERBY-280?page=comments#action_12357918 ] Satheesh Bandaram commented on DERBY-280: - I have submitted this fix to trunk. Please Resolve and Close the bug after confirming the fix. I have added a comment to indicate this problem is caused by current parser rewrite and that any fix to address Derby-681 would make this problem go away. Rick, I hope you don't mind this comment: ** This issue is caused by parser rewriting of group by/having clauses ** into table expressions. (See function tableExpression() in this file) ** There is an improvement request filed under DERBY-681 to eliminate this ** rewrite, after which it should be possible to allow multiple columns to ** have same name in the select list. Sendingjava\engine\org\apache\derby\iapi\reference\SQLState.java Sendingjava\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj Sendingjava\engine\org\apache\derby\loc\messages_en.properties Sending java\testing\org\apache\derbyTesting\functionTests\master\aggregate.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\aggregate.sql Transmitting file data . Committed revision 345304. Wrong result from select when aliasing to same name as used in group by --- Key: DERBY-280 URL: http://issues.apache.org/jira/browse/DERBY-280 Project: Derby Type: Bug Components: SQL Reporter: Bernt M. Johnsen Assignee: Rick Hillegas Priority: Minor Attachments: bug280.diff Wrong result from select when aliasing to same name as used in group by. Example: If we have the following table: ij select * from tt; I |J --- 1 |2 2 |3 1 |2 2 |3 2 |3 5 rows selected The following select is ok: ij select i, count(*) as cnt from tt group by i; I |CNT --- 1 |2 2 |3 2 rows selected But this one returns wrong result in the aliased column: ij select i, count(*) as i from tt group by i; I |I --- 1 |1 2 |2 2 rows selected -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-280) Wrong result from select when aliasing to same name as used in group by
Hi Rick, This is committed now. Thanks for addressing all issues. Satheesh Rick Hillegas wrote: Hi Satheesh, I fixed the npe you spotted and attached the updated patch to the JIRA issue. This is ready for you to commit when you have a moment. Thanks, -Rick
Re: [jira] Commented: (DERBY-666) Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in a deadlock
I tried your repro on a build from the trunk and got a deadlock message from the embedded case, when I ran it on a clean database. I reran after that and inconsistently got sometimes deadlock and sometimes timeout - note each run will add another uncommitted row to each of the tables in the db and thus change the timing. As you say it seems like the amount of time waited is the deadlock wait time, not the lock timeout time in all cases. This seems like a bug to me. I know there are some time estimates used by the lock manager to avoid expensive time request calls in java for every lock request. Maybe this estimate is going wrong for some reason. Maybe Dan may have some advice here? /mikem ps. I guess any bug numbered 666 is destined to cause problems :-) Bryan Pendleton (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-666?page=comments#action_12357762 ] Bryan Pendleton commented on DERBY-666: --- The strange thing is, when I run the program in Embedded mode, and I get the lock timeout, the program *is* sensitive to the value of derby.locks.deadlockTimeout! If I set derby.locks.deadlockTimeout to 5, the program gives the A lock could not be obtained within the time requested. error after 5 seconds, rather than after the standard 20 seconds. So it seems that the Embedded configuration is detecting the problem as a deadlock, fundamentally; it's just reporting it back out to my program as a lock timeout rather than as a deadlock. I think I'd better stop now. I've succeeded in getting myself thoroughly confused :) Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in a deadlock -- Key: DERBY-666 URL: http://issues.apache.org/jira/browse/DERBY-666 Project: Derby Type: Improvement Components: Store Versions: 10.1.1.0 Reporter: Bryan Pendleton Priority: Minor Attachments: repro.java I was reading http://www.linux-mag.com/content/view/2134/ (good article, btw!), and it says: The next two properties are needed to diagnose concurrency (locking and deadlock) problems. *derby.locks.monitor=true logs all deadlocks that occur in the system. *derby.locks.deadlockTrace=true log a stack trace of all threads involved in lock-related rollbacks. It seems, that, in my environment, the deadlockTrace property does not log a stack trace of *all* threads involved in the deadlock. Instead, it only logs a stack trace of the *victim* thread involved in the deadlock. I think it would be very useful if the derby.locks.deadlockTrace setting could in fact log a stack trace of all involved threads. In a posting to derby-dev, Mike Matrigali noted that an earlier implementation of a similar feature had to be removed because it was too expensive in both time and space, but he suggested that there might be several possible ways to implement this in an acceptably efficient manner: A long time ago there use to be room in each lock to point at a stack trace for each lock, but that was removed to optimize the size of the lock data structure which can have many objects outstanding. And creating and storing the stack for every lock was incredibly slow and just was not very useful for any very active application. I think I was the only one who ever used it. The plan was sometime to add a per user data structure which could be filled in when it was about to wait on a lock, which would give most of what is interesting in a deadlock. The current deadlockTrace is meant to dump the lock table out to derby.log when a deadlock is encountered. I agree getting a dump of all stack traces would be very useful, and with the later jvm debug interfaces may now be possible - in earlier JVM's there weren't any java interfaces to do so. Does anyone have the code to donate to dump all thread stacks to a buffer? Mike also suggested a manual technique as a workaround; it would be useful to put this into the documentation somewhere, perhaps on the page which documents derby.locks.deadlockTrace? Here's Mike's suggestion: What I do if I can reproduce easily is set try to catch the wait by hand and then depending on the environment either send the magic signal or hit ctrl-break in the server window which will send the JVM specific thread dumps to derby.log. The magic signal, btw, is 'kill -QUIT', at least with Sun JVMs in my experience.
Re: [jira] Commented: (DERBY-280) Wrong result from select when aliasing to same name as used in group by
Thanks, Satheesh! Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-280?page=comments#action_12357918 ] Satheesh Bandaram commented on DERBY-280: - I have submitted this fix to trunk. Please Resolve and Close the bug after confirming the fix. I have added a comment to indicate this problem is caused by current parser rewrite and that any fix to address Derby-681 would make this problem go away. Rick, I hope you don't mind this comment: ** This issue is caused by parser rewriting of group by/having clauses ** into table expressions. (See function tableExpression() in this file) ** There is an improvement request filed under DERBY-681 to eliminate this ** rewrite, after which it should be possible to allow multiple columns to ** have same name in the select list. Sendingjava\engine\org\apache\derby\iapi\reference\SQLState.java Sendingjava\engine\org\apache\derby\impl\sql\compile\sqlgrammar.jj Sendingjava\engine\org\apache\derby\loc\messages_en.properties Sending java\testing\org\apache\derbyTesting\functionTests\master\aggregate.out Sending java\testing\org\apache\derbyTesting\functionTests\tests\lang\aggregate.sql Transmitting file data . Committed revision 345304. Wrong result from select when aliasing to same name as used in group by --- Key: DERBY-280 URL: http://issues.apache.org/jira/browse/DERBY-280 Project: Derby Type: Bug Components: SQL Reporter: Bernt M. Johnsen Assignee: Rick Hillegas Priority: Minor Attachments: bug280.diff Wrong result from select when aliasing to same name as used in group by. Example: If we have the following table: ij select * from tt; I |J --- 1 |2 2 |3 1 |2 2 |3 2 |3 5 rows selected The following select is ok: ij select i, count(*) as cnt from tt group by i; I |CNT --- 1 |2 2 |3 2 rows selected But this one returns wrong result in the aliased column: ij select i, count(*) as i from tt group by i; I |I --- 1 |1 2 |2 2 rows selected
[jira] Commented: (DERBY-713) CLONE - Query optimizer should not make poor choices when optimizing IN and WHERE clauses
[ http://issues.apache.org/jira/browse/DERBY-713?page=comments#action_12357922 ] Satheesh Bandaram commented on DERBY-713: - If possible, rewriting the query select * from tbl where i1 in (-1,10) to select * from tbl where i1= -1 UNION select * from tbl where i1=10 could improve performance. Current Derby's OR/IN clause processing can be improved, but would need significant amount of work. CLONE - Query optimizer should not make poor choices when optimizing IN and WHERE clauses - Key: DERBY-713 URL: http://issues.apache.org/jira/browse/DERBY-713 Project: Derby Type: Improvement Components: SQL Versions: 10.0.2.0 Environment: all Reporter: Daniel James Neades Consider a simple case of - A table tbl has 1 rows, there is a primary key index on i1 and the query in question is select * from tbl where i1 in (-1,10) derby does a table scan of the entire table even though the IN list has only two values and the comparison is on a field that has an index. Briefly looking at the code, it seems like we insert a between and use the IN list to get the start and stop values for the scan. Thus the range of the values in the IN list here plays an important role. Thus if the query was changed to select * from tbl where i1 in (-1, 1), an index scan would be chosen. It would be nice if we could do something clever in this case where there is clearly an index on the field and the number of values in the IN list is known. Maybe use the rowcount estimate and the IN list size to do some optimizations. - consider the length of the IN list to do searches on the table. ie use the IN list values to do index key searches on the table, -or try to convert it to a join. Use the IN list values to create a temporary table and do a join. It is most likely that the optimizer will choose the table with IN list here as the outer table in the join and thus will do key searches on the larger table. --- some query plans that I logged using derby.language.logQueryPlan=true for some similar queries: Table has ascending values from 0 - for i1. primary key index on i1. GMT Thread[UT0,5,main] (XID = 19941), (SESSIONID = 0), select * from scanfixed where i1 in (-1,,9998,9997,9996,9995,9994,9993,9992,9991,9990) *** Project-Restrict ResultSet (2): Number of opens = 1 Rows seen = 1 Rows filtered = 9990 restriction = true projection = false constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 restriction time (milliseconds) = 0 projection time (milliseconds) = 0 optimizer estimated row count: 750.38 optimizer estimated cost: 8579.46 Source result set: Table Scan ResultSet for SCANFIXED at read committed isolation level using instantaneous share row locking chosen by the optimizer Number of opens = 1 Rows seen = 1 Rows filtered = 0 Fetch Size = 16 constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 next time in milliseconds/row = 0 scan information: Bit set of columns fetched=All Number of columns fetched=9 Number of pages visited=417 Number of rows qualified=1 Number of rows visited=1 Scan type=heap start position: null stop position: null qualifiers: Column[0][0] Id: 0 Operator: = Ordered nulls: false Unknown return value: false Negate comparison result: false Column[0][1] Id: 0 Operator: Ordered nulls: false Unknown return value: true Negate comparison result: true optimizer estimated row count: 750.38 optimizer estimated cost: 8579.46 --- l 2004-10-14 18:59:47.577 GMT Thread[UT0,5,main] (XID = 19216), (SESSIONID = 0), select * from scanfixed where i1 in (,9998,9997,9996,9995,9994,9993,9992,9991,9990) *** Project-Restrict ResultSet (3): Number of opens = 1 Rows seen = 10 Rows filtered = 0 restriction = true projection = true constructor time (milliseconds) = 0 open time (milliseconds) = 0 next time (milliseconds) = 0 close time (milliseconds) = 0 restriction time (milliseconds) = 0 projection time (milliseconds) = 0 optimizer estimated
UpdateNode/DeleteNode and SYNONYM
I was fixing some code in the bind() for UpdateNode and DeleteNode for
DERBY-571 and noticed that the methods are very similar and possibly
could be combined.
One thing that stood out is that UpdateNode has this code at the
beginning of bind() related to SYNONYMs
// check if targetTable is a synonym
if (targetTableName != null)
{
TableName synonymTab =
resolveTableToSynonym(this.targetTableName);
if (synonymTab != null)
this.targetTableName = synonymTab;
}
DeleteNode does not have this code.
However, both nodes call verifyTargetTable(), which also performs the
same SYNONYM lookup.
Is the code in UpdateNode required, or is it just left over from the
implementation by mistake?
Any ideas?
Dan.
Re: [Derby-573]Upgrade code and metadata.properties
Mamta Satoor wrote: Hi, I am working on writing the upgrade code for metadata.properties changes because of optimizer overrides syntax change. Also, I am trying to see if I can use org.apache.derbyTesting.upgradeTests.phaseTester (checked in by Dan couple months back) to test this particular upgrade scenario. The changes for hard upgrade is not so bad because in DD_version.doFullUpgrade(), I can drop the stored prepared statements (using the method dropJDBCMetadataSPSes) and then recreate them. I am still struggling with soft upgrade, though. In soft upgrade mode, the sysstatements table will get metadata queries using old optimizer override syntax which is not recognized by 10.2 but because we are in soft upgrade mode, I can't update the sysstatements table to use the new syntax. So, somehow, I need to use the queries with the new syntax but w/o updating the system table so the pre-10.2 database can be used by pre-10.2 derby release. I decided to tackle this issue by avoiding going to sysstatements table for few of these DatabaseMetaData calls(which use the optimizer overrides in their sql) and instead, just read the sql from metadata.properties and execute the sql directly. Assuming you can fix the internal SQL problem, a more generic solution would be to always use the new sql from metadata.properties when in soft-upgrade mode. That would help out future developers by removing soft-upgrade as an issue for all metadata. Dan.
Derby Driver
Hello I probably have a rather simple question, when I execute the following line Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance(); it throws the following exception java.lang.ClassNotFoundException: org.apache.derby.jdbc.EmbeddedDriverderby.jar is included in my Classpath, what is the problem?Thanks!!
Yahoo! FareChase - Search multiple travel sites in one click.
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Here is a possible solution to the versioned message id problem: o The message resolver needs two pieces of information from its callers: 1) the actual message ID, 2) the derby version that its caller was compiled at. o The names of built message files need to encode the derby version number. Then the message resolver can look up a version-specific string corresponding to the message id. In practice this would mean the following: o All calls to the message resolver can be rototilled with an extra argument which holds a constant, DERBY_VERSION. The value of this constant can be bumped with each release. o The Derby build can create message files whose names contain the current value of DERBY_VERSION. So, for example, the build would create m17_en.1012.properties instead of m17_en.properties. And code would throw exceptions like this: throw StandardException.newException(SQLState.DERBY_VERSION, SQLState.LANG_SYNTAX_ERROR, feature); rather than throw StandardException.newException(SQLState.LANG_SYNTAX_ERROR, feature);
[jira] Created: (DERBY-714) NullPointerException or ClassCastException if UPDATE or DELETE is performed on a diagnostic VTI
NullPointerException or ClassCastException if UPDATE or DELETE is performed on a diagnostic VTI --- Key: DERBY-714 URL: http://issues.apache.org/jira/browse/DERBY-714 Project: Derby Type: Bug Components: SQL Versions: 10.1.1.0, 10.0.2.0 Reporter: Daniel John Debrunner Assigned to: Daniel John Debrunner Priority: Trivial Fix For: 10.2.0.0 UPDATE and DELETE statements on read-only vtis will hit NullPointerException in insane mode, and ClassCastException in sane mode. ij delete from new org.apache.derby.diag.TransactionTable(); ERROR XJ001: Java exception: ': java.lang.NullPointerException'. While these statements make no sense, a more graceful error should be returned, especially as in insane mode this causes the engine to shutdown. Code already exists to detect this situation but is not being called. Found through adding negative tests for DERBY-571 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: UpdateNode/DeleteNode and SYNONYM
It may be possible to differ this synonym resolution to
verifyTargetTable(), but this is currently called after some cursor bind
checking that expects correct target table name. If verifyTargetTable()
can be performed before this cursor checking, which resolves synonyms
correctly, the following code can be removed.
Satheesh
Daniel John Debrunner wrote:
I was fixing some code in the bind() for UpdateNode and DeleteNode for
DERBY-571 and noticed that the methods are very similar and possibly
could be combined.
One thing that stood out is that UpdateNode has this code at the
beginning of bind() related to SYNONYMs
// check if targetTable is a synonym
if (targetTableName != null)
{
TableName synonymTab =
resolveTableToSynonym(this.targetTableName);
if (synonymTab != null)
this.targetTableName = synonymTab;
}
DeleteNode does not have this code.
However, both nodes call verifyTargetTable(), which also performs the
same SYNONYM lookup.
Is the code in UpdateNode required, or is it just left over from the
implementation by mistake?
Any ideas?
Dan.
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Rick Hillegas wrote: Here is a possible solution to the versioned message id problem: [snip details ...] o The Derby build can create message files whose names contain the current value of DERBY_VERSION. [snip more details]... If the derby build is going to create extra message files, why not one for server and one for client with different names. All that has to be encoded in the message id is whether it is client, server or both. Then there is no versioning worries I think.No?
Re: Cannot make web site changes visible: svn: Can't open file '.svn/lock': Permission denied
[EMAIL PROTECTED] wrote: Jean T. Anderson wrote: What groups are you in, Oyvind? You need to be in 'db' -- are you? I thought it might be a group thing. -bash-2.05b$ groups bakksjo apcvs incubator Exactly. Oyvind, you should be in the 'db' group now. -jean
Test Harness useprocess=false question
The test harness can run tests within the same jvm if useprocess=false. This is set for the nist suite, so that all the sub-scripts are run in a single JVM, mainly for performance reasons. I'm looking at the code in RunTest.java so I can add security manager to this in-process mode. The buildTestCommand() method is called regardless of the setting of useprocess, though it seems its result is only used for useprocess=true. Thus it seems that the call to buildTestCommand could move into the same if (useprocess) block around line 438. This leads me to the question, it seems buildTestCommand() performs a some amount of setup through property setting with -D that does not occur when running in process (useprocess=false). Apart from the security properties, the console encoding is set in buildTestCommand(), but there doesn't seem to be a corresponding setting in the in-process way. Is this intentional, or a source for concern? Thanks, Dan.
Re: Derby Driver
Seems like a classpath issue...is your application using the default JVM classloader On the command-line, can you run: (you need to have derby.jar or derbytools.jar in the classpath) java org.apache.derby.tools.sysinfo Do you get the same ClassNotFound exception?On 11/17/05, Sean McCully [EMAIL PROTECTED] wrote: Hello I probably have a rather simple question, when I execute the following line Class.forName(org.apache.derby.jdbc.EmbeddedDriver).newInstance(); it throws the following exception java.lang.ClassNotFoundException : org.apache.derby.jdbc.EmbeddedDriverderby.jar is included in my Classpath, what is the problem?Thanks!! Yahoo! FareChase - Search multiple travel sites in one click.
Re: Derby Driver
Btw, this kind of question should be posted to derby-user mailing list preferrably...On 11/17/05, Francois Orsini [EMAIL PROTECTED] wrote:Seems like a classpath issue...is your application using the default JVM classloader On the command-line, can you run: (you need to have derby.jar or derbytools.jar in the classpath) java org.apache.derby.tools.sysinfo Do you get the same ClassNotFound exception?On 11/17/05, Sean McCully [EMAIL PROTECTED] wrote: Hello I probably have a rather simple question, when I execute the following line Class.forName(org.apache.derby.jdbc.EmbeddedDriver).newInstance(); it throws the following exception java.lang.ClassNotFoundException : org.apache.derby.jdbc.EmbeddedDriverderby.jar is included in my Classpath, what is the problem?Thanks!! Yahoo! FareChase - Search multiple travel sites in one click.
Re: Derby Driver
Apologies should I continue the discussion here or move it?Yes when I execute the derby jar it works, and actually I was able to get the driver to load by merely replacing the String name with a String constant but on subsequents loads it failed. Also this may be due to the computer I was using which experienced acrashed afterwards. I will check tommorrow and move this discussion to the derby-user mailing list.Thanks!!Francois Orsini [EMAIL PROTECTED] wrote: Btw, this kind of question should be posted to derby-user mailing list preferrably... On 11/17/05, Francois Orsini [EMAIL PROTECTED] wrote: Seems like a classpath issue...is your application using the default JVM classloader On the command-line, can you run: (you need to have derby.jar or derbytools.jar in the classpath)java org.apache.derby.tools.sysinfoDo you get the same ClassNotFound exception?On 11/17/05, Sean McCully [EMAIL PROTECTED] wrote: Hello I probably have a rather simple question, when I execute the following line
Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance(); it throws the following exception java.lang.ClassNotFoundException : org.apache.derby.jdbc.EmbeddedDriverderby.jar is included in my Classpath, what is the problem?Thanks!! Yahoo! FareChase - Search multiple travel sites in one click.
Yahoo! FareChase - Search multiple travel sites in one click.
Re: [jira] Updated: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
I have tested this patch and reviewed the changes and have commited it as svn 345355. I have the following suggestions from review, and will look at any subsequent changes in these areas that Suresh would like to submit: o RawStore.java!canStartOnlineBackup() has a todo item - needs an exception error to be thrown. o will things like sort and temporary containers cause online backup to wait if they are outstanding? Does the pre-existing backup cause sorts and temp tables to be logged during online backup? (these questions probably apply to BaseDataFileFactory.java) o could you pick one place in the code to describe how all the routines work together to provide the functionality you need. I think basically put the description that you have in the JIRA for this patch somewhere in the code. The individual routines have comments but it hard to see how they all work together without one place descibing the interaction. o as I was reviewing I fixed some 80 line stuff. I know sometimes it is hard, but at least stuff like comments is really easy. o may be interesting to add external sort testing and queries that cause temp tables. probably dependent on answer to above question. Suresh Thalamati (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-239?page=all ] Suresh Thalamati updated DERBY-239: --- Attachment: onlinebackup_3.diff This patch adds code to support real-time online backup with unlogged operations. A consistent backup can not be made if there are pending transactions with unlogged operations or if unlogged operations occur when backup is in progress. Because container files can be copied to the backup before the transaction is committed and the data pages are flushed as part of the commit. As there is no transaction log for unlogged operations, while restoring from the backup database can not be restored to a consistent state. To make a consistent online backup in this scenario, this patch: 1) blocks online backup until all the transactions with unlogged operation are committed/aborted. 2) implicitly converts all unlogged operations to logged mode for the duration of the online backup, if they are started when backup is in progress. This patch also adds a test to test the online backup in parallel with some DML, DDL and unlogged operations. TESTS : derbyall test suite passed on Windows XP/JDK142 It would be great if some can review and commit this patch. svn stat: M java\engine\org\apache\derby\impl\store\raw\xact\Xact.java M java\engine\org\apache\derby\impl\store\raw\xact\XactFactory.java M java\engine\org\apache\derby\impl\store\raw\RawStore.java M java\engine\org\apache\derby\impl\store\raw\data\BaseDataFileFactory.java M java\engine\org\apache\derby\iapi\store\raw\xact\RawTransaction.java M java\engine\org\apache\derby\iapi\store\raw\xact\TransactionFactory.java M java\testing\org\apache\derbyTesting\functionTests\tests\storetests\st_1.sql A java\testing\org\apache\derbyTesting\functionTests\tests\store\OnlineBackupTest1_app.properties A java\testing\org\apache\derbyTesting\functionTests\tests\store\OnlineBackup.java M java\testing\org\apache\derbyTesting\functionTests\tests\store\copyfiles.ant A java\testing\org\apache\derbyTesting\functionTests\tests\store\OnlineBackupTest1.java M java\testing\org\apache\derbyTesting\functionTests\master\st_1.out A java\testing\org\apache\derbyTesting\functionTests\master\OnlineBackupTest1.out M java\testing\org\apache\derbyTesting\functionTests\suites\storemore.runall Need a online backup feature that does not block update operations when online backup is in progress. Key: DERBY-239 URL: http://issues.apache.org/jira/browse/DERBY-239 Project: Derby Type: New Feature Components: Store Versions: 10.1.1.0 Reporter: Suresh Thalamati Assignee: Suresh Thalamati Attachments: onlinebackup.html, onlinebackup_1.diff, onlinebackup_2.diff, onlinebackup_3.diff Currently Derby allows users to perfoms online backups using SYSCS_UTIL.SYSCS_BACKUP_DATABASE() procedure, but while the backup is in progress, update operations are temporarily blocked, but read operations can still proceed. Blocking update operations can be real issue specifically in client server environments, because user requests will be blocked for a long time if a backup is in the progress on the server.
Re: Test Harness useprocess=false question
On 11/17/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: The test harness can run tests within the same jvm if useprocess=false.This is set for the nist suite, so that all the sub-scripts are run in a single JVM, mainly for performance reasons.I'm looking at the code in RunTest.java so I can add security manager tothis in-process mode.The buildTestCommand() method is called regardless of the setting of useprocess, though it seems its result is only used for useprocess=true.Thus it seems that the call to buildTestCommand could move into the sameif (useprocess) block around line 438.This leads me to the question, it seems buildTestCommand() performs a some amount of setup through property setting with -D that does notoccur when running in process (useprocess=false).Apart from the security properties, the console encoding is set inbuildTestCommand(), but there doesn't seem to be a corresponding setting in the in-process way.Is this intentional, or a source for concern?Thanks,Dan. I need useprocess alsofor DERBY-413...:-) I think it is like this - someone please correct me if it looks I'm off... Settingencodingis being done in both createPropString() andbuildTestCommand(). This is needed because when useprocess is false, the properties need to be passed on to the resulting process that will actually run the test with -D, not just put out tothe existing properties. So, the result from createPropString is used both directly inexecTestProcess() and indirectly, via buildtestCommand() in execTestNoProcess().When there is no separate process kicked off, test harness classes that require encoding info (and other details) pick the settings up directly from the properties string. So, encoding and other settings are being set in two places, butboth should get picked up in different ways with and without useprocess. This also implies that any tests that need special flags cannot be run with useprocess = false. I think you're right that buildtestCommand can be moved inside the if(useprocess) block. Myrna
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Hi Kathey, What you say is true if the classpath contains an embedded Derby app and a client app. But I don't think it works if the classpath contains two embedded Derby apps or two client apps (at different version levels). I think that encoding a version number makes all cases work. If for some reason we have to distinguish client from server messages, then we could add that information to the encoded file names. I suppose that the message resolver could pick a client vs server message file based on a peek at the call stack and knowledge about what packages live in which jar files. Cheers, -Rick Kathey Marsden wrote: Rick Hillegas wrote: Here is a possible solution to the versioned message id problem: [snip details ...] o The Derby build can create message files whose names contain the current value of DERBY_VERSION. [snip more details]... If the derby build is going to create extra message files, why not one for server and one for client with different names. All that has to be encoded in the message id is whether it is client, server or both. Then there is no versioning worries I think.No?
[jira] Created: (DERBY-715) lock deadlocks sometimes reported as lock timeouts
lock deadlocks sometimes reported as lock timeouts -- Key: DERBY-715 URL: http://issues.apache.org/jira/browse/DERBY-715 Project: Derby Type: Bug Components: Services Versions: 10.0.2.0 Reporter: Mike Matrigali Assigned to: Mike Matrigali Priority: Minor Fix For: 10.2.0.0 Sometimes a lock deadlock is reported as a lock timeout, even when the software has done a deadlock search and found it to be a deadlock. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Rick Hillegas wrote: Hi Kathey, What you say is true if the classpath contains an embedded Derby app and a client app. But I don't think it works if the classpath contains two embedded Derby apps or two client apps (at different version levels). I think that encoding a version number makes all cases work. You can't have two client apps at different version levels in the same classloader. The one loaded first will win. If they are in different classloaders then they are separated anyway. We are looking at mixing a single derbyclient.jar (version X) with a single derby.jar (version Y) and we need to separate the m17_en.properties file when mixing the two jars. We can differentiate on the version (#releases ever different files) or on server vs client. (2 different files) so it seemed to me 2 was better until I read the next part of your mail ... If for some reason we have to distinguish client from server messages, then we could add that information to the encoded file names. I suppose that the message resolver could pick a client vs server message file based on a peek at the call stack and knowledge about what packages live in which jar files. This is a really good point about how to determine whether to load the server or client messages since these are static methods in MessageService. So I guess that part is what would be really hard. I don't understand what you said about how to do it. Sounds complicated. Kathey
[jira] Created: (DERBY-716) Re-enable VTIs
Re-enable VTIs -- Key: DERBY-716 URL: http://issues.apache.org/jira/browse/DERBY-716 Project: Derby Type: New Feature Reporter: Rick Hillegas Cloudscape used to expose Virtual Table Interfaces, by which any class which implemented ResultSet could be included in a query's FROM list. Derby still exposes a number of these VTIs as diagnostic tools. However, Derby now prevents customers from declaring their own VTIs. The parser raises an error if a VTI's package isn't one of the Derby diagnostic packages. This is a very powerful feature which customers can use to solve many problems. We should discuss the reasons that it was disabled and come up with a plan for putting this power back into our customers' hands. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re-enabling VTIs
I have logged enhancement request 716 to track the re-enabling of customer-defined Virtual Table Interfaces (VTIs). A little history follows: Cloudscape used to let users include arbitrary customer written ResultSets in the FROM lists of queries. This provided a very powerful ability to impose a tabular face on external data and to join relational data with external data streams. It is hard to overestimate the usefulness of this feature. Today, Derby still ships a number of diagnostic VTIs. However, customer-written VTIs have been disabled. The parser raises an error when it sees a VTI that doesn't live in Derby's diagnostic packages. I would like to develop a plan for addressing the concerns which led to the disabling of this feature. I would like to see us put this power back in our customer's hands. I can imagine that the non-standard nature of VTI declaration was an issue. Are there other issues? Has anyone given some thought to what a more acceptable API would look like? Thanks, -Rick
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
I don't understand what you mean by distinguish client from server messages. Client messages would be in client-messages.properties, server messages are in m_*.properties. When the engine asks for a message, it specifies the appropriate m_*.properties file based on message id. When the client asks for a message, it specified client-messages.properties as the resource file. In both cases, in the model I proposed, we look in common-messages.properties to see if the message id is there first, and then look in the client or server message properties file. I think Kathey's suggestion of copying the common message file twice, with different names for client and server, should work. I also am interested in Kathey's idea that there is just a single message file, and that the build separates out the client-specific and engine-specific messages. I have to think about that some more... David Kathey Marsden wrote: Rick Hillegas wrote: Hi Kathey, What you say is true if the classpath contains an embedded Derby app and a client app. But I don't think it works if the classpath contains two embedded Derby apps or two client apps (at different version levels). I think that encoding a version number makes all cases work. You can't have two client apps at different version levels in the same classloader. The one loaded first will win. If they are in different classloaders then they are separated anyway. We are looking at mixing a single derbyclient.jar (version X) with a single derby.jar (version Y) and we need to separate the m17_en.properties file when mixing the two jars. We can differentiate on the version (#releases ever different files) or on server vs client. (2 different files) so it seemed to me 2 was better until I read the next part of your mail ... If for some reason we have to distinguish client from server messages, then we could add that information to the encoded file names. I suppose that the message resolver could pick a client vs server message file based on a peek at the call stack and knowledge about what packages live in which jar files. This is a really good point about how to determine whether to load the server or client messages since these are static methods in MessageService. So I guess that part is what would be really hard. I don't understand what you said about how to do it. Sounds complicated. Kathey begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
[jira] Updated: (DERBY-715) lock deadlocks sometimes reported as lock timeouts
[ http://issues.apache.org/jira/browse/DERBY-715?page=all ] Mike Matrigali updated DERBY-715: - Attachment: repro.java slightly altered repro from the one bryan posted to DERBY-666, mostly just some extra prints. On my ~2 ghz single processor laptop, running windows and jdk1.4.2 when I run the test the first time I get a deadlock, and then mostly get timeouts reported for subsequent runs. Note that the first time there are 0 rows in the table, but after each iteration there are some committed deleted rows which changes the internal timing - to the user since the test never commits there are always no rows in the tables. It is clear that the time to the timeout is the deadlock time - NOT the timeout time. lock deadlocks sometimes reported as lock timeouts -- Key: DERBY-715 URL: http://issues.apache.org/jira/browse/DERBY-715 Project: Derby Type: Bug Components: Services Versions: 10.0.2.0 Reporter: Mike Matrigali Assignee: Mike Matrigali Priority: Minor Fix For: 10.2.0.0 Attachments: repro.java Sometimes a lock deadlock is reported as a lock timeout, even when the software has done a deadlock search and found it to be a deadlock. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
By the way, this solves the message versioning problem, but doesn't solve the overall forward/backward compatibility issue and the code cruft that it will engender. In reading Kathey's email, I also seem to understand that there are issues beyond code compatibility. In particular, we seem to have a hardcoded dependency on system properties (rather than say a properties file which can be loaded via a classloader), which means multiple app instances in the same VM can pollute each others' configurations even if you use multiple classloaders; it's like having system-wide global variables ala COBOL or Fortran... If we are saying we support multiple apps in the same VM, isn't this a bug? I am thinking of logging a JIRA on this. David Kathey Marsden wrote: Rick Hillegas wrote: Hi Kathey, What you say is true if the classpath contains an embedded Derby app and a client app. But I don't think it works if the classpath contains two embedded Derby apps or two client apps (at different version levels). I think that encoding a version number makes all cases work. You can't have two client apps at different version levels in the same classloader. The one loaded first will win. If they are in different classloaders then they are separated anyway. We are looking at mixing a single derbyclient.jar (version X) with a single derby.jar (version Y) and we need to separate the m17_en.properties file when mixing the two jars. We can differentiate on the version (#releases ever different files) or on server vs client. (2 different files) so it seemed to me 2 was better until I read the next part of your mail ... If for some reason we have to distinguish client from server messages, then we could add that information to the encoded file names. I suppose that the message resolver could pick a client vs server message file based on a peek at the call stack and knowledge about what packages live in which jar files. This is a really good point about how to determine whether to load the server or client messages since these are static methods in MessageService. So I guess that part is what would be really hard. I don't understand what you said about how to do it. Sounds complicated. Kathey begin:vcard fn:David W Van Couvering n:Van Couvering;David W org:Sun Microsystems, Inc.;Database Technology Group email;internet:[EMAIL PROTECTED] title:Senior Staff Software Engineer tel;work:510-550-6819 tel;cell:510-684-7281 x-mozilla-html:TRUE version:2.1 end:vcard
[jira] Updated: (DERBY-715) lock deadlocks sometimes reported as lock timeouts
[ http://issues.apache.org/jira/browse/DERBY-715?page=all ] Mike Matrigali updated DERBY-715: - Attachment: derby715.diff I have not run tests on this diff yet, just posting to get some input on whether I am on the right track or not. Do not commit this patch until I have had a chance to get it reviewed and run tests. lock deadlocks sometimes reported as lock timeouts -- Key: DERBY-715 URL: http://issues.apache.org/jira/browse/DERBY-715 Project: Derby Type: Bug Components: Services Versions: 10.0.2.0 Reporter: Mike Matrigali Assignee: Mike Matrigali Priority: Minor Fix For: 10.2.0.0 Attachments: derby715.diff, repro.java Sometimes a lock deadlock is reported as a lock timeout, even when the software has done a deadlock search and found it to be a deadlock. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-587) Providing JDBC 4.0 support for derby
[ http://issues.apache.org/jira/browse/DERBY-587?page=comments#action_12357948 ] Jean T. Anderson commented on DERBY-587: Narayanan's icla now shows up as being recorded -- so go ahead and commit, Satheesh. Providing JDBC 4.0 support for derby Key: DERBY-587 URL: http://issues.apache.org/jira/browse/DERBY-587 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: jdbc4.0.sxw, jdbc4.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Derby Driver
Sean McCully wrote: Apologies should I continue the discussion here or move it? Yes when I execute the derby jar it works, and actually I was able to get the driver to load by merely replacing the String name with a String constant but on subsequents loads it failed. Also this may be due to the computer I was using which experienced a crashed afterwards. I will check tommorrow and move this discussion to the derby-user mailing list. Thanks!! */ SNIP ... /* On 11/17/05, *Sean McCully* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello I probably have a rather simple question, when I execute the following line Class.forName(org.apache.derby.jdbc.EmbeddedDriver).newInstance(); it throws the following exception java.lang.ClassNotFoundException : org.apache.derby.jdbc.EmbeddedDriver derby.jar is included in my Classpath, what is the problem? Hi Sean - Are you using and IDE or executing in a server environment? In these cases you need to be sure that derby.jar is in the classpath of the Server / IDE. Hope it's something as easy as this.
Re: [jira] Commented: (DERBY-587) Providing JDBC 4.0 support for derby
Narayanan's icla now shows up as being recorded Yay! So does mine! http://people.apache.org/~jim/committers.html#unlistedclas bryan
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Hi Kathey, Some comments follow. Cheers-Rick Kathey Marsden wrote: ... You can't have two client apps at different version levels in the same classloader. The one loaded first will win. I'm not so sure this is true. If classes are added/deleted to/from the public API, then it may be possible to get behind the shadowing jar file. I think there are wormholes and heisenbugs in here. ... If for some reason we have to distinguish client from server messages, then we could add that information to the encoded file names. I suppose that the message resolver could pick a client vs server message file based on a peek at the call stack and knowledge about what packages live in which jar files. This is a really good point about how to determine whether to load the server or client messages since these are static methods in MessageService. So I guess that part is what would be really hard. I don't understand what you said about how to do it. Sounds complicated. Kathey You can peek at the stack using Throwable.getStackTrace(). Done wrong, it could be a brittle piece of code. In any event, I don't recommend this approach because I think that versioned message files solve the problem of messages shared between client and server.
Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
I think having 2 embedded Derby or 2 client derby apps at different version levels in the same JVM is wrong. It is technically feasible but is it rational? Separate classloaders should be used if one intends to run 2 different versions of embedded derby in the same JVM. Actually, of one of the embedded application requires a particular version of Derby, this last one better be first in the classpath - if the second one does not have a strict requirement on the version of Derby to run, then having 2 different 2 different derby.jar in the classpath is pointless...I thought we had discussed that different classloaders should be used if 2 different versions of embedded Derby (or Derby client) should run in the same JVM...
RE: Re-enabling VTIs
I for one, see the power of this feature and welcome it back in the fold. We are moving in a direction that would either 1) place our own VTIs under the diag namespace (ugly) or 2) shipping a slightly modified form (ugly) or 3) petitioning to get this added back in. The VTI API should have the ability to: - get at the full qualifier list of the given query (right now, it gets partial list depending on what operators are used) - IQualifier needs to be a notify API, not a you must do all filtering API (see enhanceement 703). - How do joins get indicated if the VTI can quickly build a hashed lookup on an identifier? IN other words, if I have a data structure that is indexed somehow, and the VTI is exposing that data, and then is joined with another similar VTI, can the engine take advantage of an index? - I would like the VTI to be exposed in the metadata of the database - I need the current syntax to be kept or augmented without removing the ability to parameterize a VTI. Thanksmaybe I'll think of more! -Original Message- From: Rick Hillegas [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 7:26 PM To: Derby Development Subject: Re-enabling VTIs I have logged enhancement request 716 to track the re-enabling of customer-defined Virtual Table Interfaces (VTIs). A little history follows: Cloudscape used to let users include arbitrary customer written ResultSets in the FROM lists of queries. This provided a very powerful ability to impose a tabular face on external data and to join relational data with external data streams. It is hard to overestimate the usefulness of this feature. Today, Derby still ships a number of diagnostic VTIs. However, customer-written VTIs have been disabled. The parser raises an error when it sees a VTI that doesn't live in Derby's diagnostic packages. I would like to develop a plan for addressing the concerns which led to the disabling of this feature. I would like to see us put this power back in our customer's hands. I can imagine that the non-standard nature of VTI declaration was an issue. Are there other issues? Has anyone given some thought to what a more acceptable API would look like? Thanks, -Rick
[jira] Commented: (DERBY-587) Providing JDBC 4.0 support for derby
[ http://issues.apache.org/jira/browse/DERBY-587?page=comments#action_12357950 ] Satheesh Bandaram commented on DERBY-587: - I have submitted this patch. Thanks everyone! Providing JDBC 4.0 support for derby Key: DERBY-587 URL: http://issues.apache.org/jira/browse/DERBY-587 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: jdbc4.0.sxw, jdbc4.diff -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Re-enabling VTIs
Rick Hillegas wrote: I have logged enhancement request 716 to track the re-enabling of customer-defined Virtual Table Interfaces (VTIs). A little history follows: I can imagine that the non-standard nature of VTI declaration was an issue. Are there other issues? Has anyone given some thought to what a more acceptable API would look like? See the comments for DERBY-571 http://issues.apache.org/jira/browse/DERBY-571 Dan.
Re: [jira] Commented: (DERBY-587) Providing JDBC 4.0 support for derby
Hi, Thanx for the help with the icla Jean. Thank you Satheesh and Rick for guiding me through the various details of the patch. Thanx to everyone for the reviews and the comments. Narayanan Satheesh Bandaram (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-587?page=comments#action_12357950 ] Satheesh Bandaram commented on DERBY-587: - I have submitted this patch. Thanks everyone! Providing JDBC 4.0 support for derby Key: DERBY-587 URL: http://issues.apache.org/jira/browse/DERBY-587 Project: Derby Type: New Feature Components: JDBC Versions: 10.2.0.0 Reporter: V.Narayanan Assignee: V.Narayanan Priority: Minor Fix For: 10.2.0.0 Attachments: jdbc4.0.sxw, jdbc4.diff
Re: Dan could you take a look at this lock manager change? Re: [jira] Updated: (DERBY-715) lock deadlocks sometimes reported as lock timeouts
Mike Matrigali wrote: While looking at Bryan's issues with DERBY-666 I think I found the problem that I have reported in DERBY-715. It looks like deadlockWait is being used to indicate a deadlock was encountered, but in some cases it is false even if a deadlock was encountered. A question I have is if this was just a wrong use of deadlockWait, or if the real problem is the path through the code that sees a deadlock and does not set this variable. I'd feel a little more confident if I understood the timing nature of the problem. The change here just uses the return value from the actual deadlock routine, which seems straight forward. It seemed to fix the problem for this test case. I'll run the tests on this change, but was just hoping for a quick note to say if I was on the right track. Looks like the right track. I think the issue is that the thread that gets picked as the victim has already performed a deadlock check without seeing a deadlock, so its deadlockWait is false. So deadlockWait = true means I'm waiting and will perform a deadlock check when I wake. It should not be used to determine if a deadlock did occur, for that deadlockData != null is the check. I think your fix needs the same change in other places, basically whenever willQuiteWait is true, the code should use deadlockData and not deadlockWait. Nice find, Dan. Dan.
Re: [jira] Updated: (DERBY-239) Need a online backup feature that does not block update operations when online backup is in progress.
Mike Matrigali wrote: I have tested this patch and reviewed the changes and have commited it as svn 345355. I have the following suggestions from review, and will look at any subsequent changes in these areas that Suresh would like to submit: o RawStore.java!canStartOnlineBackup() has a todo item - needs an exception error to be thrown. Working on this one, tests needed some changes when exception is thrown. Deferred it to fix it along with tests changes for the fix to do commit/rollback after the backup procedures. o will things like sort and temporary containers cause online backup to wait if they are outstanding? Backup should wait only for the real containers with non-logged operation. Does the pre-existing backup cause sorts and temp tables to be logged during online backup? (these questions probably apply to BaseDataFileFactory.java) Temp tables are not logged during the backup. I thought sort uses temp tables, will check on this one. Please let me know if you notice any of my changes are not doing the above. o could you pick one place in the code to describe how all the routines work together to provide the functionality you need. I think basically put the description that you have in the JIRA for this patch somewhere in the code. The individual routines have comments but it hard to see how they all work together without one place descibing the interaction. sure. I can do that in the main backup() routine in RawStore.java. In future may be backup code in RawStore.java should moved into a different BackupFactory class. o as I was reviewing I fixed some 80 line stuff. I know sometimes it is hard, but at least stuff like comments is really easy. hmm.. Thanks for fixing them. I better add some check to my emacs to avoid this in future. o may be interesting to add external sort testing and queries that cause temp tables. probably dependent on answer to above question. I will add a test case to make sure backup is not blocked on temp tables. Thanks -suresh
