[jira] Commented: (DERBY-2212) Add "Unique where not null" to create index

[Anurag Shekhar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535435
 ] 

Anurag Shekhar commented on DERBY-2212:
---

thanks Mike for revisiting the issue.

I felt letting the index remain unique will be better because 

1. It avoids the need of rescanning the index to check for duplicates after 
every update/insert.
2. Marking the index as non unique will cause optimizer to conclude that there 
might be 
duplicate records for equal predicates (not just IS NULL case) and hence it may 
some 
times select a genuine non unique index when it could have selected this 
(almost unique)
 index. Right now (in this patch) only if there is a IS NULL in where clause 
optimizer considers 
it  to have multiple records.

Many internal routine don't use optimizer to look for records but directly 
calls out to internal store 
methods (like the  case of drop table). In such cases changes will be required 
irrespective of 
the approach we use.

> Add "Unique where not null" to create index
> ---
>
> Key: DERBY-2212
> URL: https://issues.apache.org/jira/browse/DERBY-2212
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.2.1.6
>Reporter: Oleksandr Alesinskyy
>Assignee: Anurag Shekhar
> Attachments: derby-2212preview.diff, derby-2212preview2.diff
>
>
> Derby prohibits creation of unique constraints on nullable colums (as well if 
> only some columns in the constraint list are nullable) and treat nulls in 
> unique indexes as normal values (i.e. only one row with null values in 
> indexed columns may be inserted into the table). This bahavior is very 
> restrictive, does not completely comply with SQL standards (both letter and 
> intent) as well as with business needs and intending meaning of NULL values 
> (2 null values are not considered as equal, this comparision shall return 
> NULL, and for selection criteria boolean null is treated as FALSE).
> This behavior, as far as I can see, is modelled after DB2 (and differs from 
> behavior of most other major databases, like SyBase, Oracle, etc.).
> But even DB2 provide some means to alleviate these restrictions, namely 
> "UNIQUE WHERE NOT NULL" clause for CREATE INDEX statement.
> It will be very good if such "UNIQUE WHERE NOT NULL" clause will be 
> introduced in Derby.
> Regards,
> Oleksandr Alesinskyy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1781) Process handles appear to be leaking in queries using an IN clause during concurrent DB access

[Thomas Nielsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535437
 ] 

Thomas Nielsen commented on DERBY-1781:
---

Bryan, thanks for shedding some light on the DRDAConnThread lifespan. I was 
expecting them to stay around, but I also was expecting them to be reused the 
second time I ran the repro script. This does not seem to be the case, as I see 
new DRDAConnThreads being created, and the old ones stay suspended. I guess 
there is a pool or a queue that these are placed into, but are they only reused 
after N threads are created?

The majority of surviving generations are StoredRecordHeader and RecordId 
objects as previously stated. Of the StoredRecordHeader objects 52% originate 
from store.raw.data.StoredPage.recordHeaderOnDemand() and 47% from 
store.raw.data.StoredPage.storeRecordForInsert().
There's about 2200 live StoredRecordHeader objects consuming just above 100K of 
memory. This is probably touching on the work Knut is currently doing in 
DERBY-3130.
The vast majority of RecordId objects are part of a StoredRecordHeader object, 
and originate from calls to StoredRecordHeader.getHandle().

The number of surviving generations is normally a measure of probable memory 
leaks, but in our case it does not seem to be the case at first sight. The 
StoredRecordHeader objects are referenced from the StoredPage objects in the 
page cache. They are not freed until they are evicted or cleared from the 
cache. They are intentionally kept from GC and will add to the number of 
surviving generations. The pages are not cleared from the cache until the cache 
is full and more pages need loading. The new pages will then have references to 
new StoredRecordHeader object and the unused references will be GC'ed.

This investigation was done on the main trunk. I'll give 10.2.1.1 a spin as 
well to validate that there are no significant changes here from 10.2.1.1 to 
trunk.

> Process handles appear to be leaking in queries using an IN clause during 
> concurrent DB access
> --
>
> Key: DERBY-1781
> URL: https://issues.apache.org/jira/browse/DERBY-1781
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.1
> Environment: Windows XP, Java 1.5.0_05
>Reporter: Mark Hellkamp
> Attachments: SqlStressTest.java
>
>
> We are currently using Derby embedded in our web application running on 
> Windows. When processing multiple concurrent requests we have noticed that 
> the Java process handle count continues to increase until the machine becomes 
> unresponsive. I was able to isolate the problem to Derby by running the 
> database in network mode in another process. Further investigation showed 
> that the problem could be reproduced using a select statement that has an IN 
> clause with multiple entries on the primary key column. Spawning multiple 
> threads running the same query causes the handle count to increase 
> considerably on the Derby process. The problem occurs in version 10.1.3.1 and 
> 10.2.1.1 (even worse) in both embedded and network mode. The attached test 
> program duplicates the problem. Start Derby in network mode (using 
> startNetworkServer.bat) and run the enclosed test program. The handle count 
> on the Derby process will increase and never go down short of restarting 
> Derby. Using 10.2.1.1 the handle count for the Derby process goes somewhere 
> between 1400-1500 with just two threads in my environment. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-974) ClientDriver can lose some connection properties

[JIRA]

 [ 
https://issues.apache.org/jira/browse/DERBY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jørgen Løland updated DERBY-974:


Derby Info: [Patch Available]

> ClientDriver can lose some connection properties
> 
>
> Key: DERBY-974
> URL: https://issues.apache.org/jira/browse/DERBY-974
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.1.2.1, 10.1.3.1, 10.4.0.0
> Environment: Linux, Sun JRE 1.5
>Reporter: Michael Hackett
>Assignee: Jørgen Løland
>Priority: Minor
> Attachments: ClientDriver.java-diff, derby-974-1.diff, 
> derby-974-1.stat, PropertiesTest.java
>
>
> Internally, the ClientDriver class's appendDatabaseAttributes() method uses 
> keys() on the connection properties to get a list of the property names. 
> However, this misses any properties in the default set. The correct method 
> for a Properties object is propertyNames(). This will return the same type of 
> object as keys(), but will include all properties.
> (It is unfortunate that Sun chose to make Properties a subclass of Hashtable, 
> instead of giving Properties a Hashtable, as the former exposes too much 
> implementation.)
> The fix is to simply replace calls to keys() on all Property objects to use 
> propertyNames(). A quick search revealed that this is not the only place in 
> the code base where this is done, so a more thorough scan should be made.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-974) ClientDriver can lose some connection properties

[JIRA]

 [ 
https://issues.apache.org/jira/browse/DERBY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jørgen Løland updated DERBY-974:


Attachment: derby-974-1.stat
derby-974-1.diff

The attached patch, v1, fixes the bug and adds a regression test to the jdbc4 
junit tests. The regression test connects to a database with a Properties 
object with default value create=true. Without the patch, the connection is 
refused because ClientDriver does not see the create=true property. With the 
patch, the connection works as expected.

All tests pass

> ClientDriver can lose some connection properties
> 
>
> Key: DERBY-974
> URL: https://issues.apache.org/jira/browse/DERBY-974
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.1.2.1, 10.1.3.1, 10.4.0.0
> Environment: Linux, Sun JRE 1.5
>Reporter: Michael Hackett
>Assignee: Jørgen Løland
>Priority: Minor
> Attachments: ClientDriver.java-diff, derby-974-1.diff, 
> derby-974-1.stat, PropertiesTest.java
>
>
> Internally, the ClientDriver class's appendDatabaseAttributes() method uses 
> keys() on the connection properties to get a list of the property names. 
> However, this misses any properties in the default set. The correct method 
> for a Properties object is propertyNames(). This will return the same type of 
> object as keys(), but will include all properties.
> (It is unfortunate that Sun chose to make Properties a subclass of Hashtable, 
> instead of giving Properties a Hashtable, as the former exposes too much 
> implementation.)
> The fix is to simply replace calls to keys() on all Property objects to use 
> propertyNames(). A quick search revealed that this is not the only place in 
> the code base where this is done, so a more thorough scan should be made.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: deprecation warnings with jdk15 build

[Jørgen Løland]

Myrna van Lunteren wrote:

Hi,

Now that we switched to jdk15 as the base level for the trunk, I see a
ton of deprecation warnings.
My jdk is: Sun's 1.5.0_12-b04, and I've got build.compiler set to modern

I find it bothersome and hard to see 'real' build failures like this,
but trunk/tools/ant/properties/modern.properties has deprecation set
to 'on'.
Would it be reasonable to set this to 'off' or am I the only one
seeing these warnings?
Or is there another trick I need to do?

Thx,
Myrna



Wouldn't it be even better if we fixed these? There is usually a good 
reason for deprecating methods, e.g. performance.


--
Jørgen Løland

[jira] Commented: (DERBY-2967) Single character does not match high value unicode character with collation TERRITORY_BASED

[Knut Anders Hatlen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535479
 ] 

Knut Anders Hatlen commented on DERBY-2967:
---

I read the Oct 11 patch in the commit log and I have a question about 
checkEquality(). Sorry that I didn't comment before.

It looks like checkEquality() will create two String objects and two 
CollationElementIterator objects per character we want to check. This sounds 
overly expensive to me. Do you think there is a cheaper way to achieve the same?

I have a couple of ideas which may or may not work:

a) We could use the compare() method instead of iterators. It caches and reuses 
the iterators across calls and therefore it might be more efficient. It would 
also simplify the code, since the else clause in checkEquality() could be 
rewritten to:

} else {//dealing with territory based character string
return collator.compare(new String(pat, pLoc, 1), new String(val, vLoc, 1)) 
== 0:
}

b) To eliminate *both* the String allocations and the CollationElementIterator 
allocations, I think we could allocate one CollationElementIterator for each 
string (as opposed to each character) and use setOffset()/getOffset() to ensure 
that we work on one character at a time.

> Single character does not match high value unicode character with collation 
> TERRITORY_BASED
> ---
>
> Key: DERBY-2967
> URL: https://issues.apache.org/jira/browse/DERBY-2967
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.4.0.0
>Reporter: Kathey Marsden
>Assignee: Mamta A. Satoor
> Attachments: DERBY2967_Oct11_07_diff.txt, 
> DERBY2967_Oct11_07_stat.txt, DERBY2967_offset_based_diff_Oct02_07.txt, 
> DERBY2967_offset_based_stat_Oct02_07.txt, fullcoll.out, 
> patch2_setOffset_fullcoll.out, patch2_with_setOffset_diff_Sep2007.txt, 
> patch2_with_setOffset_stat_Sep2007.txt, step1_iteratorbased_Sep1507_diff.txt, 
> step1_iteratorbased_Sep1507_stat.txt, temp_diff.txt, temp_stat.txt, 
> TestFrench.java, TestNorway.java
>
>
> With TERRITORY_BASED collation '_' does not match  the character \uFA2D.  It 
> is the same for english or norwegian. FOR collation UCS_BASIC it matches 
> fine.  Could you tell me if this is a bug?
> Here is a program to reproduce.
> import java.sql.*;
> public class HighCharacter {
>public static void main(String args[]) throws Exception
>{
>System.out.println("\n Territory no_NO");
>Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
>Connection conn = 
> DriverManager.getConnection("jdbc:derby:nordb;create=true;territory=no_NO;collation=TERRITORY_BASED");
>testLikeWithHighestValidCharacter(conn);
>conn.close();
>System.out.println("\n Territory en_US");
>conn = 
> DriverManager.getConnection("jdbc:derby:endb;create=true;territory=en_US;collation=TERRITORY_BASED");
>testLikeWithHighestValidCharacter(conn);
>conn.close();
>System.out.println("\n Collation USC_BASIC");
>conn = DriverManager.getConnection("jdbc:derby:basicdb;create=true");
>testLikeWithHighestValidCharacter(conn);
>}
> public static  void testLikeWithHighestValidCharacter(Connection conn) throws 
> SQLException {
>Statement stmt = conn.createStatement();
>try {
>stmt.executeUpdate("drop table t1");
>}catch (SQLException se)
>{// drop failure ok.
>}
>stmt.executeUpdate("create table t1(c11 int)");
>stmt.executeUpdate("insert into t1 values 1");
>  
>// \uFA2D - the highest valid character according to
>// Character.isDefined() of JDK 1.4;
>PreparedStatement ps =
>conn.prepareStatement("select 1 from t1 where '\uFA2D' like ?");
>  String[] match = { "%", "_", "\uFA2D" };
>for (int i = 0; i < match.length; i++) {
>System.out.println("select 1 from t1 where '\\uFA2D' like " + match[i]);
>ps.setString(1, match[i]);
>ResultSet rs = ps.executeQuery();
>if( rs.next() && rs.getString(1).equals("1"))
>System.out.println("PASS");
>else  System.out.println("FAIL: no match");
>rs.close();
>}
>   }
> }
> Mamta made some comments on this issue in the following thread:
> http://www.nabble.com/Single-character-does-not-match-high-value-unicode-character-with-collation-TERRITORY_BASED.-Is-this-a-bug-tf4118767.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: deprecation warnings with jdk15 build

[Knut Anders Hatlen]

Jørgen Løland <[EMAIL PROTECTED]> writes:

> Myrna van Lunteren wrote:
>> Hi,
>>
>> Now that we switched to jdk15 as the base level for the trunk, I see a
>> ton of deprecation warnings.
>> My jdk is: Sun's 1.5.0_12-b04, and I've got build.compiler set to modern
>>
>> I find it bothersome and hard to see 'real' build failures like this,
>> but trunk/tools/ant/properties/modern.properties has deprecation set
>> to 'on'.
>> Would it be reasonable to set this to 'off' or am I the only one
>> seeing these warnings?
>> Or is there another trick I need to do?
>>
>> Thx,
>> Myrna
>>
>
> Wouldn't it be even better if we fixed these? There is usually a good
> reason for deprecating methods, e.g. performance.

I agree. There may be cases where we want to use deprecated methods,
like in tests of JDBC methods that have been deprecated in later
versions of the spec, but then we could narrow it down to a smaller
number of files for which deprecation warnings are turned off.

-- 
Knut Anders

[jira] Commented: (DERBY-1781) Process handles appear to be leaking in queries using an IN clause during concurrent DB access

[Thomas Nielsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535490
 ] 

Thomas Nielsen commented on DERBY-1781:
---

Running the repro a few more times in sequence show that the NetworkServer is 
well behaved and is actually reusing the DRDAConnThreads.

> Process handles appear to be leaking in queries using an IN clause during 
> concurrent DB access
> --
>
> Key: DERBY-1781
> URL: https://issues.apache.org/jira/browse/DERBY-1781
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.1
> Environment: Windows XP, Java 1.5.0_05
>Reporter: Mark Hellkamp
> Attachments: SqlStressTest.java
>
>
> We are currently using Derby embedded in our web application running on 
> Windows. When processing multiple concurrent requests we have noticed that 
> the Java process handle count continues to increase until the machine becomes 
> unresponsive. I was able to isolate the problem to Derby by running the 
> database in network mode in another process. Further investigation showed 
> that the problem could be reproduced using a select statement that has an IN 
> clause with multiple entries on the primary key column. Spawning multiple 
> threads running the same query causes the handle count to increase 
> considerably on the Derby process. The problem occurs in version 10.1.3.1 and 
> 10.2.1.1 (even worse) in both embedded and network mode. The attached test 
> program duplicates the problem. Start Derby in network mode (using 
> startNetworkServer.bat) and run the enclosed test program. The handle count 
> on the Derby process will increase and never go down short of restarting 
> Derby. Using 10.2.1.1 the handle count for the Derby process goes somewhere 
> between 1400-1500 with just two threads in my environment. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: How to donate code to Apache (Derby)

[Dyre . Tjeldvoll]

"Jean T. Anderson" <[EMAIL PROTECTED]> writes:

> this is less of an issue now at Apache because committers are only given
> accounts after the signed CLA has been recorded (it wasn't always that
> way in the past). You'll notice at
> http://people.apache.org/~jim/committers.html that some names are in
> italics -- those don't have signed CLAs and my understanding is those
> accounts have been disabled.
>
> All Derby committers have signed CLAs in place.

That's what I thought, and that's also why the paragraph didn't make
sense to me. Thanks for clearing that up.

>> 
>> "Remind active committers that they are responsible for ensuring that
>> a Corporate CLA is recorded if such is required to authorize their
>> contributions under their individual CLA."
>> 
>> I assume that 'active committers' refer to people contributing to the
>> code being donated? (As opposed to existing Derby committers). What's
>> the definition of 'active' in this context? At least one contribution
>> in the last six months?
>
> It's just easier to post that reminder to derby-dev and catch any and
> all who have contributed in the past and might contribute more in the
> future. 
>
> In an old post [1] I explained (or tried to explain) what the CCLA issue
> is. The main point is the CCLA is there to protect employees who are
> paid to work on Apache projects, and avoid any misunderstandings with
> their employer.
>
> I hope this helps.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200612.mbox/[EMAIL 
> PROTECTED]

Well, I realize now that 'active committers' refer to Derby
committers. From the above email I understand what you did, and I
think I'll be able to copy your example.

(While I see why it is important that committers have CLAs and CCLAs,
I still don't understand why this becomes more important when
considering a software grant.)

-- 
dt

[jira] Created: (DERBY-3131) Background cleaner has no daemon service after database creation

[Knut Anders Hatlen (JIRA)]

Background cleaner has no daemon service after database creation


 Key: DERBY-3131
 URL: https://issues.apache.org/jira/browse/DERBY-3131
 Project: Derby
  Issue Type: Bug
  Components: Services, Store
Affects Versions: 10.4.0.0
Reporter: Knut Anders Hatlen
Priority: Minor


When a database is booted, the page cache and the container cache are given a 
daemon service to perform operations in the background. This happens in 
BaseDataFileFactory.postRecovery(). When a new database is created this code is 
not executed (presumably because we don't perform recovery), so its background 
cleaner remains inactive until the database is rebooted. The background cleaner 
should be active after the first boot.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3131) Background cleaner has no daemon service after database creation

[Knut Anders Hatlen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535506
 ] 

Knut Anders Hatlen commented on DERBY-3131:
---

To reproduce put some println statements in Clock.useDaemonService() and try 
this in ij:

ij version 10.4
ij> connect 'jdbc:derby:mydb;create=true';  
ij> disconnect;
ij> connect 'jdbc:derby:mydb;shutdown=true';
ERROR 08006: Database 'mydb' shutdown.
ij> connect 'jdbc:derby:mydb';
useDaemonService([EMAIL PROTECTED])
name: ContainerCache
useDaemonService([EMAIL PROTECTED])
name: PageCache
ij> 

useDaemonService() is not called on the first boot, but it is called on the 
second boot.

> Background cleaner has no daemon service after database creation
> 
>
> Key: DERBY-3131
> URL: https://issues.apache.org/jira/browse/DERBY-3131
> Project: Derby
>  Issue Type: Bug
>  Components: Services, Store
>Affects Versions: 10.4.0.0
>Reporter: Knut Anders Hatlen
>Priority: Minor
>
> When a database is booted, the page cache and the container cache are given a 
> daemon service to perform operations in the background. This happens in 
> BaseDataFileFactory.postRecovery(). When a new database is created this code 
> is not executed (presumably because we don't perform recovery), so its 
> background cleaner remains inactive until the database is rebooted. The 
> background cleaner should be active after the first boot.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1781) Process handles appear to be leaking in queries using an IN clause during concurrent DB access

[Thomas Nielsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535514
 ] 

Thomas Nielsen commented on DERBY-1781:
---

The closest thing to 10.2.1.1 I had available was 10.2.1.6.

I reran the repro a single time on 10.2.1.6 and something has changed a lot 
from 10.2.1.6 and up the main trunk (10.4.0.0 alpha).

Max heapsize after *multiple* repro runs was close to 12Mb with main trunk 
(10.4.0.0 alpha), and tipped 17Mb on the *first* run with 10.2.1.6.
Max number of surviving generations was on the order of 600, dropping to 430 on 
the main trunk (10.4.0.0 alpha), but was increasing rapidly until 2000, then 
dipped to 600, and then steadily increased until 849 on 10.2.1.6.
The main trunk feels a lot faster than 10.2.1.6 to execute the N 
transactions/iterations it is supposed to do, but I haven't timed either.

The memory usage and generation counts on the main trunk are probably as 
expected (see above).

There are however two places in BasePage and StoredPage where the GC could be 
let a helping hand by possibly rewriting constructs like 
[BasePage.java @ 1379]:
   for (int slot = FIRST_SLOT_NUMBER ; slot < maxSlot; slot++) {
  if (recordHeaderOnDemand(slot).isDeleted())
 delCount++;
   }

to something like:
   StoredRecordHeader rh = null;
   for (int slot = FIRST_SLOT_NUMBER ; slot < maxSlot; slot++) {
  rh = recordHeaderOnDemand(slot);
  if (rh.isDeleted())
 delCount++;
  rh = null;
   }

to explicitly tell the GC that the StoredRecordHeader returned from 
recordHeaderOnDemand() can be gc'ed.

The latest official release, 10.3.1.4, is even more well behaved wrt to surving 
generations than the main trunk it seems. First repro run gave "only" 125 
surviving generations. Only exception is there's an int[] originating in 
DataValueFactoryImpl.setLocale() that's eating some memory which seem to have 
been fixed/changed as part of the collation work(?) on the main trunk.
And there's only 59 or so surviving generations of the StoredRecordHeader 
object in 10.3.1.4, opposed to ~400 on the main trunk.

To recap findings this far:
- the main trunk does not show the behavior reported.
- 10.2.1.6 does show an increased resource usage over the main trunk, but not 
to the point of becoming unresponsive.
- an increasing "surviving generation count" seems plausible given the nature 
of the implemented cache.
- Suggest user move to latest release, if possible, and reopen issue if it is 
still a problem.

> Process handles appear to be leaking in queries using an IN clause during 
> concurrent DB access
> --
>
> Key: DERBY-1781
> URL: https://issues.apache.org/jira/browse/DERBY-1781
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.1
> Environment: Windows XP, Java 1.5.0_05
>Reporter: Mark Hellkamp
> Attachments: SqlStressTest.java
>
>
> We are currently using Derby embedded in our web application running on 
> Windows. When processing multiple concurrent requests we have noticed that 
> the Java process handle count continues to increase until the machine becomes 
> unresponsive. I was able to isolate the problem to Derby by running the 
> database in network mode in another process. Further investigation showed 
> that the problem could be reproduced using a select statement that has an IN 
> clause with multiple entries on the primary key column. Spawning multiple 
> threads running the same query causes the handle count to increase 
> considerably on the Derby process. The problem occurs in version 10.1.3.1 and 
> 10.2.1.1 (even worse) in both embedded and network mode. The attached test 
> program duplicates the problem. Start Derby in network mode (using 
> startNetworkServer.bat) and run the enclosed test program. The handle count 
> on the Derby process will increase and never go down short of restarting 
> Derby. Using 10.2.1.1 the handle count for the Derby process goes somewhere 
> between 1400-1500 with just two threads in my environment. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2977) Replication: Add a ReplicationMaster controller that will manage replication on the master side

[JIRA]

[ 
https://issues.apache.org/jira/browse/DERBY-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535534
 ] 

Øystein Grøvlen commented on DERBY-2977:


Thanks for addressing my comments in the new patch, Jørgen.  I have
just a few minor follow-up comments (same numbering as in my previous
review):

1. Your basically looks good.  IMHO, calling the new method
   'checkForReplication' or something instead of
   'initLogAccessFileReplication' since it will not always init
   replication.  (Check is also the main verb you use to describe in
   the javadoc what it is doing.)  

   As an alternative to 'startReplicationMasterRole', I suggest
   'setReplicationMasterRole', since as I said, it is not always
   starting replication.

2. A third alternative implementation that will behave almost the same
   as the current strategy as seen from the user, is to remember any
   logFileSwitch at the end of a log chunk until the next chunk
   arrives, and let switchLogFile() be true for the first log record
   of the next chunk.  Then, removing 'else' will be the only necessary change
   to your example code.

4. As far as I can see, you have not addressed this typo.

9. I think I meant LogAccessFile#stopReplicationMasterRole.  Anyway,
   it is fixed now.

10. (NEW) To me, adding instant as a parameter to
LogAccessFile#writeToLog seems like a better solution than
maintaining a field 'instantCurrentChunk'.

None of the above issues are very important, and it is your
call whether you would like to fix any of them before I commit.

> Replication: Add a ReplicationMaster controller that will manage replication 
> on the master side
> ---
>
> Key: DERBY-2977
> URL: https://issues.apache.org/jira/browse/DERBY-2977
> Project: Derby
>  Issue Type: Sub-task
>  Components: Services
>Affects Versions: 10.4.0.0
>Reporter: Jørgen Løland
>Assignee: Jørgen Løland
> Attachments: derby_2977_1.diff, derby_2977_1.stat, 
> derby_2977_1b.diff, derby_2977_1b.stat, derby_2977_1c.diff, 
> derby_2977_1c.stat, repli_logbuffer_v2.diff, repli_logbuffer_v2.stat, 
> repli_logbuffer_v2b.diff, repli_logbuffer_v2b.stat, repli_logbuffer_v2c.diff, 
> repli_logbuffer_v2c.stat
>
>
> The replication master role includes many tasks:
> * set up a network connection to the slave
> * sending the database to the slave before starting replication
> * make sure that log records are appended to the network buffer, and that the 
> log is later sent to the slave
> * etc
> This issue is for adding a controller that will start/stop/initiate all 
> services needed for the replication master role.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-974) ClientDriver can lose some connection properties

[Knut Anders Hatlen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535535
 ] 

Knut Anders Hatlen commented on DERBY-974:
--

Rather than hard-coding the host name and the database name, I think you can 
wrap the test case in a DatabaseChangeSetup via 
TestConfiguration.singleUseDatabaseDecorator(). This will automatically 
generate a unique database name and do cleanup afterwards. Then you can get the 
JDBC URL by calling TestConfiguration.getCurrent().getJDBCUrl(). With this 
approach, it is also easier to make the test run in both embedded mode and 
client/server mode, so you don't need special code in suite().

Wouldn't it be better to skip this catch block? If the test fails, it would 
probably be more interesting to see the actual error message and its stack 
trace, so I think it is better just to let the exception propagate up to the 
caller.
+} catch (SQLNonTransientConnectionException e){
+fail("Connecting with a Properties object with "+
+ "default values does not work");
+} finally {

Does this test belong in the JDBC 4 suite? I don't see that it is testing any 
functionality specific to JDBC 4. Perhaps jdbcapi/DriverTest is a better place? 
In fact, it looks like DriverTest already has what you need to pass in a 
Properties object to getConnection(). See DriverTest.assertConnect().

> ClientDriver can lose some connection properties
> 
>
> Key: DERBY-974
> URL: https://issues.apache.org/jira/browse/DERBY-974
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Affects Versions: 10.1.2.1, 10.1.3.1, 10.4.0.0
> Environment: Linux, Sun JRE 1.5
>Reporter: Michael Hackett
>Assignee: Jørgen Løland
>Priority: Minor
> Attachments: ClientDriver.java-diff, derby-974-1.diff, 
> derby-974-1.stat, PropertiesTest.java
>
>
> Internally, the ClientDriver class's appendDatabaseAttributes() method uses 
> keys() on the connection properties to get a list of the property names. 
> However, this misses any properties in the default set. The correct method 
> for a Properties object is propertyNames(). This will return the same type of 
> object as keys(), but will include all properties.
> (It is unfortunate that Sun chose to make Properties a subclass of Hashtable, 
> instead of giving Properties a Hashtable, as the former exposes too much 
> implementation.)
> The fix is to simply replace calls to keys() on all Property objects to use 
> propertyNames(). A quick search revealed that this is not the only place in 
> the code base where this is done, so a more thorough scan should be made.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (DERBY-3064) Implement the LogShipper that will enable the shipping of Log records from the master to the slave

[V.Narayanan (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

V.Narayanan reopened DERBY-3064:



I intend to use the same issue for log shipper integration with the master 
controller. hence I am re-opening the issue.

> Implement the LogShipper that will enable the shipping of Log records from 
> the master to the slave
> --
>
> Key: DERBY-3064
> URL: https://issues.apache.org/jira/browse/DERBY-3064
> Project: Derby
>  Issue Type: Sub-task
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: LogShipperImpl_v1.diff, LogShipperImpl_v1.stat, 
> LogShipperImpl_v2.diff, LogShipperImpl_v2.stat, LogShipperImpl_v3.diff, 
> LogShipperImpl_v3.stat, LogShipperImpl_v4.diff, LogShipperImpl_v4.stat, 
> LogShipperImpl_v5.diff, LogShipperImpl_v5.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3064) Implement the LogShipper that will enable the shipping of Log records from the master to the slave

[V.Narayanan (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535545
 ] 

V.Narayanan commented on DERBY-3064:


While working on the integration of the log shipper into the 
MasterController(MC) I will be introducing code that will log MC startup,
any failures that occur and MC shutdown in derby.log. 

while printing messages in derby.log a distinction ought to be made with 
respect to the messages that will be printed
always and the messages that will be printed only during debug(sane) mode.

With respect to replication and this patch the following messages will be 
printed irrespective of whether the debug mode is on or not

1) Replication(MC) startup
2) Error conditions that occur while MC (log shipping) is running
3) Replication(MC) shutdown

> Implement the LogShipper that will enable the shipping of Log records from 
> the master to the slave
> --
>
> Key: DERBY-3064
> URL: https://issues.apache.org/jira/browse/DERBY-3064
> Project: Derby
>  Issue Type: Sub-task
>Reporter: V.Narayanan
>Assignee: V.Narayanan
> Attachments: LogShipperImpl_v1.diff, LogShipperImpl_v1.stat, 
> LogShipperImpl_v2.diff, LogShipperImpl_v2.stat, LogShipperImpl_v3.diff, 
> LogShipperImpl_v3.stat, LogShipperImpl_v4.diff, LogShipperImpl_v4.stat, 
> LogShipperImpl_v5.diff, LogShipperImpl_v5.stat
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-2240) "VALUES expression" is written "VALUES statement" in SelectExpression page of Derby Reference Manual

[Tomohito Nakayama (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535549
 ] 

Tomohito Nakayama commented on DERBY-2240:
--

We have "VALUES expression" page in reference manual. 
(http://db.apache.org/derby/docs/dev/ref/rrefsqlj11277.html)
I think this word is moderate.

> "VALUES expression" is written  "VALUES statement" in SelectExpression page 
> of Derby Reference Manual
> -
>
> Key: DERBY-2240
> URL: https://issues.apache.org/jira/browse/DERBY-2240
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
> Environment: 
> http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html
>Reporter: Tomohito Nakayama
>
> Next description 
> When a query does not have a FROM clause (when you are constructing a value, 
> not getting data out of a table), you use a VALUES statement, not a 
> SelectExpression.
> I think VALUES statement is not correct .
> It must be VALUES expression.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1781) Process handles appear to be leaking in queries using an IN clause during concurrent DB access

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535558
 ] 

Bryan Pendleton commented on DERBY-1781:


> recap findings this far: 

Thomas, thanks very much for all the investigation and experimentation, it is 
very helpful!

I think you should assign this bug to yourself, to reflect that you are 
studying it.

Given the subject of the bug, and the fact that the behavior was markedly better
in recent code, I wonder if the fix for DERBY-47 is part of the behavior 
improvements?

I see that Mark Helkamp was monitoring the "handle count", while you have been 
looking
at Java object memory usage. Are these two things the same? I am not sure how to
observe "The handle count on the Derby process", but it would be nice if we 
could confirm
that this measurement, too, is substantially improved in the trunk prior to 
marking this
issue as resolved.

> Process handles appear to be leaking in queries using an IN clause during 
> concurrent DB access
> --
>
> Key: DERBY-1781
> URL: https://issues.apache.org/jira/browse/DERBY-1781
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.1
> Environment: Windows XP, Java 1.5.0_05
>Reporter: Mark Hellkamp
> Attachments: SqlStressTest.java
>
>
> We are currently using Derby embedded in our web application running on 
> Windows. When processing multiple concurrent requests we have noticed that 
> the Java process handle count continues to increase until the machine becomes 
> unresponsive. I was able to isolate the problem to Derby by running the 
> database in network mode in another process. Further investigation showed 
> that the problem could be reproduced using a select statement that has an IN 
> clause with multiple entries on the primary key column. Spawning multiple 
> threads running the same query causes the handle count to increase 
> considerably on the Derby process. The problem occurs in version 10.1.3.1 and 
> 10.2.1.1 (even worse) in both embedded and network mode. The attached test 
> program duplicates the problem. Start Derby in network mode (using 
> startNetworkServer.bat) and run the enclosed test program. The handle count 
> on the Derby process will increase and never go down short of restarting 
> Derby. Using 10.2.1.1 the handle count for the Derby process goes somewhere 
> between 1400-1500 with just two threads in my environment. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: deprecation warnings with jdk15 build

[Myrna van Lunteren]

On 10/17/07, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
> Jørgen Løland <[EMAIL PROTECTED]> writes:
>
> > Myrna van Lunteren wrote:
> >> Hi,
> >>
> >> Now that we switched to jdk15 as the base level for the trunk, I see a
> >> ton of deprecation warnings.
> >> My jdk is: Sun's 1.5.0_12-b04, and I've got build.compiler set to modern
> >>
> >> I find it bothersome and hard to see 'real' build failures like this,
> >> but trunk/tools/ant/properties/modern.properties has deprecation set
> >> to 'on'.
> >> Would it be reasonable to set this to 'off' or am I the only one
> >> seeing these warnings?
> >> Or is there another trick I need to do?
> >>
> >> Thx,
> >> Myrna
> >>
> >
> > Wouldn't it be even better if we fixed these? There is usually a good
> > reason for deprecating methods, e.g. performance.
>
> I agree. There may be cases where we want to use deprecated methods,
> like in tests of JDBC methods that have been deprecated in later
> versions of the spec, but then we could narrow it down to a smaller
> number of files for which deprecation warnings are turned off.
>
> --
> Knut Anders
>
I think possibly a lot of the warnings I see are indeed connected to
valid use of deprecated methods - e.g.
PreparedStatement.s/getUnicodeStream...
But I logged DERBY-3132.

Myrna

[jira] Commented: (DERBY-2212) Add "Unique where not null" to create index

[Anurag Shekhar (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535561
 ] 

Anurag Shekhar commented on DERBY-2212:
---

1) Current code changes B2I so needs upgrade code or else no old database with 
any index will be able to be read.

I do have code for soft and hard upgrade in my todo list. I will create an jira 
for the same.

2) The approach seems complicated and error prone to me. Treating compare of 
nulls one way through an extra overloaded arg sometimes and sometimes seems 
overly complicated.

It is just one of the possible approach I am trying it out only because I felt 
its a good solution. I am open to take other approach.


3) I need to think about it more carefully to understand how treating compare 
of nulls differently in the same tree might affect things like logical undo 
during restart recovery after an uncommitted insert where the row may have 
moved drastically since the insert do to lots of other inserts.

I will write some tests related to this scenario and get back.

4) before commit needs a bunch of null heavy additional test cases.

Yes I need to write several test cases for new behaviour and also some make 
sure its not breaking something else in some other part of the code base.


1) optimizer probably will assume 1 row from unique index in this case, now it 
may have to use some other estimate when dealing with nulls. If the index was 
non-unique rather than unique current code would just work. 

Optimizer has a provision to treat IS NULL differently from '='. I am using 
that in my current patch and it appears to be working fine for very basic tests.

2) unique index locking isolation level algorithm is different from duplicate 
index locking isolation level for serializable. It may have to now change. 
Previously a previous key lock is not necessary to protect a "phantom" insert 
range for a unique index - after your change maybe it is? Again if the index 
was marked non-unique at implementation level then current code would just 
work. 

I need to check about it. I will test and debug the code in multi user mode and 
get back.



> Add "Unique where not null" to create index
> ---
>
> Key: DERBY-2212
> URL: https://issues.apache.org/jira/browse/DERBY-2212
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.2.1.6
>Reporter: Oleksandr Alesinskyy
>Assignee: Anurag Shekhar
> Attachments: derby-2212preview.diff, derby-2212preview2.diff
>
>
> Derby prohibits creation of unique constraints on nullable colums (as well if 
> only some columns in the constraint list are nullable) and treat nulls in 
> unique indexes as normal values (i.e. only one row with null values in 
> indexed columns may be inserted into the table). This bahavior is very 
> restrictive, does not completely comply with SQL standards (both letter and 
> intent) as well as with business needs and intending meaning of NULL values 
> (2 null values are not considered as equal, this comparision shall return 
> NULL, and for selection criteria boolean null is treated as FALSE).
> This behavior, as far as I can see, is modelled after DB2 (and differs from 
> behavior of most other major databases, like SyBase, Oracle, etc.).
> But even DB2 provide some means to alleviate these restrictions, namely 
> "UNIQUE WHERE NOT NULL" clause for CREATE INDEX statement.
> It will be very good if such "UNIQUE WHERE NOT NULL" clause will be 
> introduced in Derby.
> Regards,
> Oleksandr Alesinskyy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3095) CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS

[EDAH-TALLY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535563
 ] 

EDAH-TALLY commented on DERBY-3095:
---

Well, let's not forget the final aim of this issue.

We should be able to safely delete a non quote delimited user with at least a 
lower-case character (eve, Eve, eVe...). It is not possible right now. A 
work-around is to pass the same identifier all in uppercase (EVE) to CALL 
SYSCS_UTIL.SYSCS_SET_USER_ACCESS(CURRENT USER, NULL).

We should be able to safely delete a quote delimited user ("eve", "eVe"...). It 
is not possible. And here it's worse as there is no work around.

Such supposedly deleted users could wretch havoc in the database.

Whatever concepts are in conflict, we only expect Derby to do the job.

> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> 
>
> Key: DERBY-3095
> URL: https://issues.apache.org/jira/browse/DERBY-3095
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.3.1.4
> Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
>Reporter: EDAH-TALLY
> Attachments: 3095_00.diff, 3095_01.diff, d3095.sql, 
> REGTEST3095_00.zip, REGTEST3095_01.zip, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the 
> stack trace : 
> **
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
> at 
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.execute(Unknown 
> Source)
> at com.somecom.createUser(someAPP.java:190)
> at com.somecom.grantKeys(someAPP.java:288)
> at com.somecom.showGrantKeys(someAPP.java:269)
> at com.somecom.MDIMenuClicked(someAPP.java:620)
> at com.somecom.access$000(someAPP.java:15)
> at com.somecom$5.actionPerformed(someAPP.java:564)
> at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
> at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
> at java.awt.Component.processMouseEvent(Component.java:6038)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
> at java.awt.Component.processEvent(Component.java:5803)
> at java.awt.Container.processEvent(Container.java:2058)
> at java.awt.Component.dispatchEventImpl(Component.java:4410)
> at java.awt.Container.dispatchEventImpl(Container.java:2116)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
> at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
> at java.awt.Container.dispatchEventImpl(Container.java:2102)
> at java.awt.Window.dispatchEventImpl(Window.java:2429)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
> Caused by: org.apache.derby.client.am.SqlException: Droit d'accès 'NOACCESS' 
> inconnu.
> at org.apache.derby.client.am.Statement.completeExecute(Unknown 
> Source)
> at 
> org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown 
> Source)
> at 
> org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source)
> at org.apache.derby.client.net.StatementReply.readExecuteCall(Unkn

[jira] Commented: (DERBY-3095) CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535559
 ] 

Daniel John Debrunner commented on DERBY-3095:
--

In SQL (ie. the language) then "eve" is represented by eve. E.g. in a GRANT 
statement then "eve" and eve are two different users.

Creating users in Derby is through setting properties which  is not SQL, and 
may be inconsistent (see earlier comment).

The documentation for setting users says the user name is "case-sensitive" and 
can be a delimited identifier, that seems strange, a horrible mix of two models.
http://db.apache.org/derby/docs/dev/devguide/cdevcsecure21547.html

That page implies that the first two will be different users and the first the 
same as the third, though I don't know what would happen if you set this up.

derby.user.eve 
derby.user.EVE
derby.user."eve"

I thought there was a wiki page that had good examples for this, including how 
to pass in delimited names in JDBC. The context for that information was using 
e-mail addresses as user names, e.g. from an LDAP server. The @ sign can only 
exist in a delimited identifier.


> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> 
>
> Key: DERBY-3095
> URL: https://issues.apache.org/jira/browse/DERBY-3095
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.3.1.4
> Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
>Reporter: EDAH-TALLY
> Attachments: 3095_00.diff, 3095_01.diff, d3095.sql, 
> REGTEST3095_00.zip, REGTEST3095_01.zip, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the 
> stack trace : 
> **
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
> at 
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.execute(Unknown 
> Source)
> at com.somecom.createUser(someAPP.java:190)
> at com.somecom.grantKeys(someAPP.java:288)
> at com.somecom.showGrantKeys(someAPP.java:269)
> at com.somecom.MDIMenuClicked(someAPP.java:620)
> at com.somecom.access$000(someAPP.java:15)
> at com.somecom$5.actionPerformed(someAPP.java:564)
> at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
> at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
> at java.awt.Component.processMouseEvent(Component.java:6038)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
> at java.awt.Component.processEvent(Component.java:5803)
> at java.awt.Container.processEvent(Container.java:2058)
> at java.awt.Component.dispatchEventImpl(Component.java:4410)
> at java.awt.Container.dispatchEventImpl(Container.java:2116)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
> at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
> at java.awt.Container.dispatchEventImpl(Container.java:2102)
> at java.awt.Window.dispatchEventImpl(Window.java:2429)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
> Caused by: org.apache.derby.client.am.SqlException: Droit d'accès 'NOACCESS' 
> i

[jira] Commented: (DERBY-1781) Process handles appear to be leaking in queries using an IN clause during concurrent DB access

[Thomas Nielsen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535566
 ] 

Thomas Nielsen commented on DERBY-1781:
---

Bryan,

AFAIK the handle count on windows represents handles to both processes and 
memory pages (and all other resources that you and the OS keep track of). Given 
the steady increase in "surviving generations" seen in the profiler, my initial 
assumption was that this was actually due to leaking memory. 

DERBY-47 indeed seems like the probable fix. Thanks for keeping an eye on this 
:)

I've started a longer running repro (more iterations)  to see how things evolve 
over time. Still a little early, but things seem to stabilize at around 20mb 
heapsize and 1600 generations on the main trunk (10.4.0.0 alpha) after some 
time. This is a good indication that we are actually *not* leaking memory, and 
that the fluctuations we see in a limited number of repro runs are to be 
expected. 

I will need to compare the handle counts in the Sysinternals Process Explorer 
from both 10.2.1.6 and 10.3.1.4 after running multiple iterations, before 
resolving this issue.

> Process handles appear to be leaking in queries using an IN clause during 
> concurrent DB access
> --
>
> Key: DERBY-1781
> URL: https://issues.apache.org/jira/browse/DERBY-1781
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.1
> Environment: Windows XP, Java 1.5.0_05
>Reporter: Mark Hellkamp
> Attachments: SqlStressTest.java
>
>
> We are currently using Derby embedded in our web application running on 
> Windows. When processing multiple concurrent requests we have noticed that 
> the Java process handle count continues to increase until the machine becomes 
> unresponsive. I was able to isolate the problem to Derby by running the 
> database in network mode in another process. Further investigation showed 
> that the problem could be reproduced using a select statement that has an IN 
> clause with multiple entries on the primary key column. Spawning multiple 
> threads running the same query causes the handle count to increase 
> considerably on the Derby process. The problem occurs in version 10.1.3.1 and 
> 10.2.1.1 (even worse) in both embedded and network mode. The attached test 
> program duplicates the problem. Start Derby in network mode (using 
> startNetworkServer.bat) and run the enclosed test program. The handle count 
> on the Derby process will increase and never go down short of restarting 
> Derby. Using 10.2.1.1 the handle count for the Derby process goes somewhere 
> between 1400-1500 with just two threads in my environment. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (DERBY-1781) Process handles appear to be leaking in queries using an IN clause during concurrent DB access

[Thomas Nielsen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Nielsen reassigned DERBY-1781:
-

Assignee: Thomas Nielsen

> Process handles appear to be leaking in queries using an IN clause during 
> concurrent DB access
> --
>
> Key: DERBY-1781
> URL: https://issues.apache.org/jira/browse/DERBY-1781
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.1.3.1
> Environment: Windows XP, Java 1.5.0_05
>Reporter: Mark Hellkamp
>Assignee: Thomas Nielsen
> Attachments: SqlStressTest.java
>
>
> We are currently using Derby embedded in our web application running on 
> Windows. When processing multiple concurrent requests we have noticed that 
> the Java process handle count continues to increase until the machine becomes 
> unresponsive. I was able to isolate the problem to Derby by running the 
> database in network mode in another process. Further investigation showed 
> that the problem could be reproduced using a select statement that has an IN 
> clause with multiple entries on the primary key column. Spawning multiple 
> threads running the same query causes the handle count to increase 
> considerably on the Derby process. The problem occurs in version 10.1.3.1 and 
> 10.2.1.1 (even worse) in both embedded and network mode. The attached test 
> program duplicates the problem. Start Derby in network mode (using 
> startNetworkServer.bat) and run the enclosed test program. The handle count 
> on the Derby process will increase and never go down short of restarting 
> Derby. Using 10.2.1.1 the handle count for the Derby process goes somewhere 
> between 1400-1500 with just two threads in my environment. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DERBY-3132) deprecation warnings when building with jdk15 and build.compiler modern

[Myrna van Lunteren (JIRA)]

deprecation warnings when building with jdk15 and build.compiler modern
---

 Key: DERBY-3132
 URL: https://issues.apache.org/jira/browse/DERBY-3132
 Project: Derby
  Issue Type: Bug
  Components: Build tools
Affects Versions: 10.4.0.0
 Environment: Sun's 1.5.0_12-b04, build.compiler=modern
Reporter: Myrna van Lunteren


See this 2006 thread: 
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200605.mbox/[EMAIL 
PROTECTED]
and:
http://www.nabble.com/deprecation-warnings-with-jdk15-build-tf4637684.html#a13245300

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: deprecation warnings with jdk15 build

[Rick Hillegas]

I have set "deprecation=off" in my ant.properties. I also run ant with 
the "-quiet" switch. Those little tweaks reduce the build chatter to a 
manageable screenful and help me see the signal through the noise.


Regards,
-Rick

Myrna van Lunteren wrote:

On 10/17/07, Knut Anders Hatlen <[EMAIL PROTECTED]> wrote:
  

Jørgen Løland <[EMAIL PROTECTED]> writes:



Myrna van Lunteren wrote:
  

Hi,

Now that we switched to jdk15 as the base level for the trunk, I see a
ton of deprecation warnings.
My jdk is: Sun's 1.5.0_12-b04, and I've got build.compiler set to modern

I find it bothersome and hard to see 'real' build failures like this,
but trunk/tools/ant/properties/modern.properties has deprecation set
to 'on'.
Would it be reasonable to set this to 'off' or am I the only one
seeing these warnings?
Or is there another trick I need to do?

Thx,
Myrna



Wouldn't it be even better if we fixed these? There is usually a good
reason for deprecating methods, e.g. performance.
  

I agree. There may be cases where we want to use deprecated methods,
like in tests of JDBC methods that have been deprecated in later
versions of the spec, but then we could narrow it down to a smaller
number of files for which deprecation warnings are turned off.

--
Knut Anders



I think possibly a lot of the warnings I see are indeed connected to
valid use of deprecated methods - e.g.
PreparedStatement.s/getUnicodeStream...
But I logged DERBY-3132.

Myrna
  

[jira] Subscription: Derby: JIRA issues with patch available

[jira]

Issue Subscription
Filter: Derby: JIRA issues with patch available (20 issues)
Subscriber: derby-dev


Key Summary
DERBY-974   ClientDriver can lose some connection properties
https://issues.apache.org/jira/browse/DERBY-974
DERBY-2977  Replication: Add a ReplicationMaster controller that will manage 
replication on the master side
https://issues.apache.org/jira/browse/DERBY-2977
DERBY-2967  Single character does not match high value unicode character with 
collation TERRITORY_BASED
https://issues.apache.org/jira/browse/DERBY-2967
DERBY-1387  Add JMX extensions to Derby
https://issues.apache.org/jira/browse/DERBY-1387
DERBY-3117  Adjust master build script to require the Java 5 compiler to build 
Derby
https://issues.apache.org/jira/browse/DERBY-3117
DERBY-223   Change programs under demo directory use consistent package names 
so IDEs do not report errors
https://issues.apache.org/jira/browse/DERBY-223
DERBY-2065  Network and embedded difference in SQLSTATE and message when 
Connection.close() with open transaction.
https://issues.apache.org/jira/browse/DERBY-2065
DERBY-3071  Replication: Modify logging subsystem for slave replication mode
https://issues.apache.org/jira/browse/DERBY-3071
DERBY-3109  Nonexistent property derby.database.defaultAccessMode shown in 
Developers Guide: User Authentication examples
https://issues.apache.org/jira/browse/DERBY-3109
DERBY-2905  Shutting down embedded Derby does not remove all code, the 
AutoloadDriver is left registered in the DriverManager.
https://issues.apache.org/jira/browse/DERBY-2905
DERBY-3069  Derby does not resolve functions bound to methods with varargs.
https://issues.apache.org/jira/browse/DERBY-3069
DERBY-1272  Change sysinfo to print to error log (derby.log) on boot of derby  
if derby.stream.error.logSeverityLevel=0
https://issues.apache.org/jira/browse/DERBY-1272
DERBY-3072  User documentation for Table Functions
https://issues.apache.org/jira/browse/DERBY-3072
DERBY-2182  Documentation for derby.system.bootAll is missing
https://issues.apache.org/jira/browse/DERBY-2182
DERBY-2953  Dump the information about rollbacks of the global transaction 
(introduced in DERBY-2220 and DERBY-2432) to derby.log
https://issues.apache.org/jira/browse/DERBY-2953
DERBY-2789  DatabaseMetaData .locatorsUpdateCopy() should return true
https://issues.apache.org/jira/browse/DERBY-2789
DERBY-2798  A new approach for main-memory database
https://issues.apache.org/jira/browse/DERBY-2798
DERBY-2815  ij doesn't start with J2ME / JSR169 / weme6.1 because attempting to 
find java.sql.Driver if ij.protocol property is specified
https://issues.apache.org/jira/browse/DERBY-2815
DERBY-2807  Create a test for BlobClob compatibility on Derby server versions 
vs. Derby client versions.
https://issues.apache.org/jira/browse/DERBY-2807
DERBY-2255  ij should indicate that it is waiting for more input in a 
multi-line interactive statement.
https://issues.apache.org/jira/browse/DERBY-2255

Regression Test Report - Daily 584809 - Sun DBTG

[Henri . Vandescheur]

[Auto-generated mail]

*Daily* 584809/2007-10-15 18:00:11 CEST

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
 lin
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sles
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sol
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 solN+1
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sparc
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 vista
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 w2003
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-584809.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/584809_bySig.html 

*Jvm: 1.5*
 lin
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sles
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sol
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 solN+1
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sparc
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 vista
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 w2003
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-584809.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/584809_bySig.html 

*Jvm: 1.4*
 lin
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sles
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sol
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 solN+1
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 sparc
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 vista
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
 w2003
   NA NA NANA   derbyall
   NA NA NANA   suitesAll
  Details in  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-584809.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/584809_bySig.html 

---

Changes in  http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/584809.txt 

( All results in http://dbtg.thresher.com/derby/test/ ) 

[jira] Commented: (DERBY-2240) "VALUES expression" is written "VALUES statement" in SelectExpression page of Derby Reference Manual

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535603
 ] 

Daniel John Debrunner commented on DERBY-2240:
--

The SQL standard name for this use of VALUES is  

Note that Derby does have a VALUES statement, e.g. VALUES 1,2,3

> "VALUES expression" is written  "VALUES statement" in SelectExpression page 
> of Derby Reference Manual
> -
>
> Key: DERBY-2240
> URL: https://issues.apache.org/jira/browse/DERBY-2240
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
> Environment: 
> http://db.apache.org/derby/docs/dev/ref/rrefselectexpression.html
>Reporter: Tomohito Nakayama
>
> Next description 
> When a query does not have a FROM clause (when you are constructing a value, 
> not getting data out of a table), you use a VALUES statement, not a 
> SelectExpression.
> I think VALUES statement is not correct .
> It must be VALUES expression.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3095) CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535615
 ] 

Daniel John Debrunner commented on DERBY-3095:
--

I agree there's a bug, I just want to ensure any change still works correctly 
when CURRENT_USER name is passed in.

My assertion is that the username passed into these routines (without any 
modification) is equivalent to value of an username identifier in the SQL 
language after it has been parsed by the SQL engine. This is also known as "how 
it is stored in the SQL engine" [JDBC].

VALUES SYSCS_UTIL.SYSCS_GET_USER_ACCESS('eVe'); -- corresponds to the 
identifier "eVe"
VALUES SYSCS_UTIL.SYSCS_GET_USER_ACCESS('EVE'); -- corresponds to the identifer 
eve, EVE, "EVE" or EvE etc.

Note that though how users names are represented in the derby.* properties may 
or may not match how a SQL engine would store them. For historical reasons in 
some (all?)  cases the values in a derby.* property may be as a delimited 
identifier, e.g. "eVe".

Note that the Derby builtin users are not created through a SQL identifier in 
the SQL language, e.g. in a CREATE USER statement. They are created by setting 
properties and are thus not "stored in the SQL engine".

Is that what your patch does? From the comments in this jira entry and the code 
I can't really tell the behaviour you are trying to achieve.





> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> 
>
> Key: DERBY-3095
> URL: https://issues.apache.org/jira/browse/DERBY-3095
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.3.1.4
> Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
>Reporter: EDAH-TALLY
> Attachments: 3095_00.diff, 3095_01.diff, d3095.sql, 
> REGTEST3095_00.zip, REGTEST3095_01.zip, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the 
> stack trace : 
> **
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
> at 
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.execute(Unknown 
> Source)
> at com.somecom.createUser(someAPP.java:190)
> at com.somecom.grantKeys(someAPP.java:288)
> at com.somecom.showGrantKeys(someAPP.java:269)
> at com.somecom.MDIMenuClicked(someAPP.java:620)
> at com.somecom.access$000(someAPP.java:15)
> at com.somecom$5.actionPerformed(someAPP.java:564)
> at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
> at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
> at java.awt.Component.processMouseEvent(Component.java:6038)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
> at java.awt.Component.processEvent(Component.java:5803)
> at java.awt.Container.processEvent(Container.java:2058)
> at java.awt.Component.dispatchEventImpl(Component.java:4410)
> at java.awt.Container.dispatchEventImpl(Container.java:2116)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
> at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
> at java.awt.Container.dispatchEventImpl(Container.java:2102)
> at java.awt.Window.dispatchEventImpl(Window.java:2429)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)

[jira] Updated: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Rick Hillegas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-3117:
-

Attachment: derby_source.html
derby-3117-02-website-aa.diff

Thanks for the pointer to that page, John. That page seems to be generally 
out-of-date. For instance, it still tells people to install jdk 1.3 and the 
jdk1.3 extension jars. I am attaching a patch which updates the website's build 
instructions (derby-3117-02-website-aa.diff) and the corresponding html output 
derby_source.html.

> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-857) LDAP user authentication fails under a security manager

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535628
 ] 

Kathey Marsden commented on DERBY-857:
--

Running with  -Djava.security.debug="access,failure,jar,domain" I get this more 
interesting trace, but still no clue as to who needs the socket permissions.   
I am not sure that there is a fix for this.  I think maybe we have to document 
the workaround to  put 

grant {
  permission java.net.SocketPermission "", "connect,resolve";
};

in the policy file for LDAP. Anyone have thoughts on this?


access: access denied (java.net.SocketPermission  resolve)

java.lang.Exception: Stack trace

at java.lang.Thread.dumpStack(Thread.java:1206)

at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:313)

at 
java.security.AccessController.checkPermission(AccessController.java:546)

at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)

at java.lang.SecurityManager.checkConnect(SecurityManager.java:1031)

at java.net.InetAddress.getAllByName0(InetAddress.java:1128)

at java.net.InetAddress.getAllByName0(InetAddress.java:1109)

at java.net.InetAddress.getAllByName(InetAddress.java:1072)

at java.net.InetAddress.getByName(InetAddress.java:969)

at java.net.InetSocketAddress.(InetSocketAddress.java:124)

at java.net.Socket.(Socket.java:179)

at com.sun.jndi.ldap.Connection.createSocket(Connection.java:349)

at com.sun.jndi.ldap.Connection.(Connection.java:184)

at com.sun.jndi.ldap.LdapClient.(LdapClient.java:118)

at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1580)

at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2616)

at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:287)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)

at 
com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)

at 
com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)

at 
com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)

at 
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)

at 
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)

at javax.naming.InitialContext.init(InitialContext.java:223)

at javax.naming.InitialContext.(InitialContext.java:197)

at 
javax.naming.directory.InitialDirContext.(InitialDirContext.java:82)

at 
org.apache.derby.impl.jdbc.authentication.LDAPAuthenticationSchemeImpl.getDNFromUID(LDAPAuthenticationSchemeImpl.java:442)

at 
org.apache.derby.impl.jdbc.authentication.LDAPAuthenticationSchemeImpl.authenticateUser(LDAPAuthenticationSchemeImpl.java:160)

at 
org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.authenticate(AuthenticationServiceBase.java:222)

at 
org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(EmbedConnection.java:583)

at 
org.apache.derby.impl.jdbc.EmbedConnection.(EmbedConnection.java:301)

at 
org.apache.derby.impl.jdbc.EmbedConnection30.(EmbedConnection30.java:73)

at 
org.apache.derby.impl.jdbc.EmbedConnection40.(EmbedConnection40.java:54)

at 
org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:68)

at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:211)

at 
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:119)

at java.sql.DriverManager.getConnection(DriverManager.java:582)

at java.sql.DriverManager.getConnection(DriverManager.java:154)

at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:1206)

at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:1056)

at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:884)

at 
org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:328)

at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:248)

at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)

at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)

at org.apache.derby.impl.tools.ij.Main.main(Main.java:73)

at org.apache.derby.tools.ij.main(ij.java:59)



> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > E

[jira] Commented: (DERBY-3095) CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535636
 ] 

Daniel John Debrunner commented on DERBY-3095:
--

I added an (incomplete) page to describe how user identifiers (should) work in 
Derby.

http://wiki.apache.org/db-derby/UserIdentifiers

> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> 
>
> Key: DERBY-3095
> URL: https://issues.apache.org/jira/browse/DERBY-3095
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.3.1.4
> Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
>Reporter: EDAH-TALLY
> Attachments: 3095_00.diff, 3095_01.diff, d3095.sql, 
> REGTEST3095_00.zip, REGTEST3095_01.zip, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the 
> stack trace : 
> **
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
> at 
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.execute(Unknown 
> Source)
> at com.somecom.createUser(someAPP.java:190)
> at com.somecom.grantKeys(someAPP.java:288)
> at com.somecom.showGrantKeys(someAPP.java:269)
> at com.somecom.MDIMenuClicked(someAPP.java:620)
> at com.somecom.access$000(someAPP.java:15)
> at com.somecom$5.actionPerformed(someAPP.java:564)
> at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
> at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
> at java.awt.Component.processMouseEvent(Component.java:6038)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
> at java.awt.Component.processEvent(Component.java:5803)
> at java.awt.Container.processEvent(Container.java:2058)
> at java.awt.Component.dispatchEventImpl(Component.java:4410)
> at java.awt.Container.dispatchEventImpl(Container.java:2116)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
> at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
> at java.awt.Container.dispatchEventImpl(Container.java:2102)
> at java.awt.Window.dispatchEventImpl(Window.java:2429)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
> at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
> Caused by: org.apache.derby.client.am.SqlException: Droit d'accès 'NOACCESS' 
> inconnu.
> at org.apache.derby.client.am.Statement.completeExecute(Unknown 
> Source)
> at 
> org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown 
> Source)
> at 
> org.apache.derby.client.net.NetStatementReply.readExecuteCall(Unknown Source)
> at org.apache.derby.client.net.StatementReply.readExecuteCall(Unknown 
> Source)
> at org.apache.derby.client.net.NetStatement.readExecuteCall_(Unknown 
> Source)
> at org.apache.derby.client.am.Statement.readExecuteCall(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.flowExecute(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.executeX(Unknown 
> Source)
> ... 34 more
> **

Making Derby a top level Apache project

[Rick Hillegas]

Recently, the DB PMC discussed whether we should make Derby a top level 
Apache project. The consensus seemed to be that a) Derby is mature 
enough to be a top level project, b) no-one felt passionately one way or 
another, c) therefore this decision should be left to the Derby 
community. It seemed to me that the major argument for promoting Derby 
to be a top level project was


+ This would increase Derby's visibility.

The major argument against promoting Derby to the top level was

- This would force us to rototill our website.

What do you think? Should we move Derby to the top level?

Thanks,
-Rick

[jira] Commented: (DERBY-857) LDAP user authentication fails under a security manager

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535642
 ] 

Daniel John Debrunner commented on DERBY-857:
-

How about just removing the code, since it's just sanity and isn't really a 
benefit?

Or just catching the security exception and continuing?

I think the code was probably put there during the original development of LDAP 
authentication, I doubt it's needed now.

> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException: 
> > noSuchMachine:389 [Root exception is java.security.AccessControlException: 
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv 
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Knut Anders Hatlen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535661
 ] 

Knut Anders Hatlen commented on DERBY-3117:
---

How are we going to set up ${java15compile.classpath}? I see two options:

  1) Introduce a j15lib variable in ant.properties, like we do for Java 1.4

  2) Automatically set it based on ${java.home}

Although 2 is simpler, I think 1 is best since it prevents accidental 
introduction of dependencies on Java 6 (or higher) if we build with a more 
recent JDK.

> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-857) LDAP user authentication fails under a security manager

[Kathey Marsden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden updated DERBY-857:
-

Attachment: derby-857_diff.txt

This first patch adds a privilege block around creation of the tracing file. If 
creation of the tracing file fails, execution will continue.  It does not cause 
the core problem of making a connection to the LDAP server if we don't include 

grant {
  permission java.net.SocketPermission "", "resolve,connect";
};


> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
> Attachments: derby-857_diff.txt
>
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException: 
> > noSuchMachine:389 [Root exception is java.security.AccessControlException: 
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv 
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-857) LDAP user authentication fails under a security manager

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535656
 ] 

Kathey Marsden commented on DERBY-857:
--

Dan said
>How about just removing the code, since it's just sanity and isn't really a 
>benefit?

>Or just catching the security exception and continuing?

>I think the code was probably put there during the original development of 
>LDAP authentication, I doubt it's >needed now.
>

The original security exception was for the tracing and I was able to resolve 
that by adding a privilege block around the code. (It could also be removed.) 
That got me further but the problem now is in the heart of the LDAP processing, 
in .LDAPAuthenticationSchemeImpl.authenticateUser where we call:

// it is happening right here
 DirContext ctx = privInitialDirContext(env);


and get
ERROR 08004: Connection refused : javax.naming.CommunicationException: 
socket.usca.ibm.com:389 [Root exception is 
java.security.AccessControlException: access denied (java.net.SocketPermission 
socket.usca.ibm.com resolve)]

I will go ahead and post the patch for the change to get us past the tracing 
file problem so that you can see the same failure I am seeing.  You can see it 
is a javax.naming.CommunicationException that is thrown not a Security 
Excepition, so wrapping this call in a privilege block is not helpful.

Kathey


> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException: 
> > noSuchMachine:389 [Root exception is java.security.AccessControlException: 
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv 
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-857) LDAP user authentication fails under a security manager

[Kathey Marsden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden updated DERBY-857:
-

Derby Info: [Patch Available]

> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
> Attachments: derby-857_diff.txt
>
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException: 
> > noSuchMachine:389 [Root exception is java.security.AccessControlException: 
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv 
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3093) intermittent transaction failure caused by internal duplicate savepoint name, for tirgger

[Knut Anders Hatlen (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535673
 ] 

Knut Anders Hatlen commented on DERBY-3093:
---

That's a good catch, James! Seems like you have found the bug. If the savepoint 
name only needs to be unique within a transaction, I think we can fix it by 
maintaining a counter in GenericLanguageConnectionContext and adding a 
getUniqueSavepointName() method which returns "ISSP1", "ISSP2", ...

> intermittent transaction failure caused by internal duplicate savepoint name, 
> for tirgger
> -
>
> Key: DERBY-3093
> URL: https://issues.apache.org/jira/browse/DERBY-3093
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.3.1.4
> Environment: Java 1.6.0_02
>Reporter: Jim Newsham
>
> While running our app overnight, performing some intensive database 
> operations (primarily deletes), we experienced a transaction failure, with 
> error message "A SAVEPOINT with the passed name already exists in the current 
> transaction".  This failure appears to be very intermittent, as I've run the 
> same operation successfully for hours and hours without failure.  Some more 
> information:
> 1.  I see that there are four JIRA issues which report the same message 
> (DERBY-2773, DERBY-1457, DERBY-2808, DERBY-2804).  I am not sure to what 
> extent if any, the problem I experienced is related to these issues.
> • At least three of the above JIRA issues are related to triggers.  Our 
> transaction failure occurred while performing a delete in a table which has 
> delete triggers.
> • We aren't using savepoints explicitly.  Of course, it can be seen in 
> the stack trace that the trigger operation is setting a savepoint.
> • One of the JIRA issues mentions exceeding maximum depth of nested 
> triggers.  Not sure what a nested trigger is, but the trigger we are 
> performing should not (in theory) cause another trigger event.
> 2.  Here's the stack trace:
> Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already 
> exists in the current transaction.
> 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 
> com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase$3.perform(DerbySampleBase.java:682)
> at 
> com.referentia.sdf.monitor.samplebase.derby.DerbySampleBase.performInTransaction(DerbySampleBase.java:2747)
> ... 7 more
> Caused by: java.sql.SQLException: A SAVEPOINT with the passed name already 
> exists in the current transaction.
> at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at 
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
>  Source)
> ... 18 more
> Caused by: ERROR 3B501: A SAVEPOINT with the passed name already exists in 
> the current transaction.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown 
> Source)
> at org.apache.derby.impl.store.raw.xact.Xact.setSavePoint(Unknown 
> Source)
> at 
> org.apache.derby.impl.store.access.RAMTransaction.setSavePoint(Unknown Source)
> at 
> org.apache.derby.impl.sql.conn.GenericStatementContext.setSavePoint(Unknown 
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source)
> at 
> org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(Unknown 
> Source)
> at 
> org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(Unknown 
> Source)
> at 
> org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(Unknown 
> Source)
> at 
> org.apache.derby.impl.sql.execute.DeleteResultSet.fireAfterTriggers(Unknown 
> Source)
> at org.apache.derby.impl.sql.execute.DeleteResultSet.open(Unknown 
> Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source)
> ... 12 more
> 3.  Here are the relevant tables and trigger

[jira] Commented: (DERBY-2807) Create a test for BlobClob compatibility on Derby server versions vs. Derby client versions.

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535672
 ] 

Kathey Marsden commented on DERBY-2807:
---

Running CompatiblitySuite with the patch I get the exception below. Is there 
some special setup required?

java.lang.NullPointerException
at 
org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.faultInDriver(DerbyJUnitTest.java:334)
at 
org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:371)
at 
org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:356)
at 
org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.JDBCDriverTest.testJDBCDriver(JDBCDriverTest.java:252)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at 
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at 
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)



> Create a test for BlobClob compatibility on Derby server versions vs. Derby 
> client versions.
> 
>
> Key: DERBY-2807
> URL: https://issues.apache.org/jira/browse/DERBY-2807
> Project: Derby
>  Issue Type: Improvement
>  Components: Test
>Affects Versions: 10.3.1.4
>Reporter: Ole Solberg
>Assignee: Ole Solberg
>Priority: Minor
> Attachments: derby-2807-v1.diff.txt
>
>
> Run '/tests/jdbcapi/BlobClob4BlobTest.java' in the 
> 'java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/CompatibilityCombinations.java'
>  framework to test combinations of Derby server versions vs. Derby client 
> versions. The CompatibilityCombinations framework also allows varying the JVM 
> version used on the server and client side.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535674
 ] 

Rick Hillegas commented on DERBY-3117:
--

Hi Knut,

Can you help me understand why we need a java15compile.classpath?

Thanks!

> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535682
 ] 

Daniel John Debrunner commented on DERBY-3117:
--

To compile code that requires Java 1.5 classes or methods.

> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

[Kim Haase (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kim Haase updated DERBY-1823:
-

   Derby Info: [Patch Available]
Affects Version/s: 10.1.2.1
   10.1.3.1
   10.2.1.6
   10.2.2.0
   10.3.1.4

> Derby Developer's Guide -  Issues w/ User authentication and authorization 
> extended examples section/paragraph
> --
>
> Key: DERBY-1823
> URL: https://issues.apache.org/jira/browse/DERBY-1823
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 
> 10.3.1.4
>Reporter: Francois Orsini
>Assignee: Kim Haase
>Priority: Minor
> Attachments: DERBY-1823.diff, DERBY-1823.zip
>
>
> There is a couple of issues with the paragraph/section  "User authentication 
> and authorization extended examples" in the developer's guide
> http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure26537.html
> 1) The methods turnOnBuiltInUsers() & turnOffBuiltInUsers() do NOT shutdown 
> and reboot the database for which the 
> 'derby.connection.requireAuthentication' authentication database property is 
> being set - as this last one is a derby static property, it will not be taken 
> into account until the database is rebooted (or the whole derby engine 
> instance). Hence, the 2 checks for "Confirming requireAuthentication" is 
> misleading as the property value is changed _but_ the actual database 
> authentication enabling/disabling has not changed since it was last booted. 
> Database needs to be shutdown and rebooted after 
> 'derby.connection.requireAuthentication' is set and then some negative 
> testing of invalid user connection needs to be added to show that only valid 
> users can connect (in the case, authentication is being enabled).
> 2) Paragraph (extended examples section) also needs to be moved at the same 
> level as the 2 above such as:
>   "User authentication example in a single-user, embedded environment"
>   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure125.html
>   "User authentication example in a client/server environment"
>   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure13713.html
> since the extended examples (once fixed - see 1)) can be applied in both a 
> client-server and embedded environments context.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-1823) Derby Developer's Guide - Issues w/ User authentication and authorization extended examples section/paragraph

[Kim Haase (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kim Haase updated DERBY-1823:
-

Attachment: DERBY-1823.zip
DERBY-1823.diff

I'm attaching a patch (DERBY-1823.diff and DERBY-1823.zip) that contains the 
following changes:

M  src/devguide/rdevcsecure26537.dita
A  src/devguide/rdevcsecureclientexample.dita
M  src/devguide/derbydev.ditamap

rdevcsecure26537.dita now contains an end-to-end embedded example. I've added a 
file with a client example, rdevcsecureclientexample.dita. The client example 
had to be split into two source files run in sequence, even though you don't 
have to shut down and restart the Network Server in between. 

I left the examples nested under their respective parent files (on 
client/server and embedded examples) in the TOC.

Please let me know if further changes are needed. I'm still waiting for 
approval of the fix to one of the parent files (DERBY-3109).


> Derby Developer's Guide -  Issues w/ User authentication and authorization 
> extended examples section/paragraph
> --
>
> Key: DERBY-1823
> URL: https://issues.apache.org/jira/browse/DERBY-1823
> Project: Derby
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 
> 10.3.1.4
>Reporter: Francois Orsini
>Assignee: Kim Haase
>Priority: Minor
> Attachments: DERBY-1823.diff, DERBY-1823.zip
>
>
> There is a couple of issues with the paragraph/section  "User authentication 
> and authorization extended examples" in the developer's guide
> http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure26537.html
> 1) The methods turnOnBuiltInUsers() & turnOffBuiltInUsers() do NOT shutdown 
> and reboot the database for which the 
> 'derby.connection.requireAuthentication' authentication database property is 
> being set - as this last one is a derby static property, it will not be taken 
> into account until the database is rebooted (or the whole derby engine 
> instance). Hence, the 2 checks for "Confirming requireAuthentication" is 
> misleading as the property value is changed _but_ the actual database 
> authentication enabling/disabling has not changed since it was last booted. 
> Database needs to be shutdown and rebooted after 
> 'derby.connection.requireAuthentication' is set and then some negative 
> testing of invalid user connection needs to be added to show that only valid 
> users can connect (in the case, authentication is being enabled).
> 2) Paragraph (extended examples section) also needs to be moved at the same 
> level as the 2 above such as:
>   "User authentication example in a single-user, embedded environment"
>   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure125.html
>   "User authentication example in a client/server environment"
>   http://db.apache.org/derby/docs/10.2/devguide/rdevcsecure13713.html
> since the extended examples (once fixed - see 1)) can be applied in both a 
> client-server and embedded environments context.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535707
 ] 

Rick Hillegas commented on DERBY-3117:
--

I don't see why we need this variable to compile code that requires Java 5 
classes and methods. Won't the compiler's default classpath be good enough now 
that we're requiring a Java 5 or higher compiler? Thanks.

> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535716
 ] 

Daniel John Debrunner commented on DERBY-3117:
--

No. Imagine you are writing a class that needs to run on Java 5 but are using 
JDK 6 as your classpath. If you use the compilers default class path then you 
run the risk of introducing methods/classes into the Java5 code that are only 
in JDK 6.

It's just like when there was a jdk13 classpath property even though a jdk 1.4 
compiler was required.

> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535716
 ] 

djd edited comment on DERBY-3117 at 10/17/07 1:16 PM:


No. Imagine you are writing a class that needs to run on Java 5 but are using 
JDK 6 as your compiler. If you use the compilers default class path then you 
run the risk of introducing methods/classes into the Java5 code that are only 
in JDK 6.

It's just like when there was a jdk13 classpath property even though a jdk 1.4 
compiler was required.

  was (Author: djd):
No. Imagine you are writing a class that needs to run on Java 5 but are 
using JDK 6 as your classpath. If you use the compilers default class path then 
you run the risk of introducing methods/classes into the Java5 code that are 
only in JDK 6.

It's just like when there was a jdk13 classpath property even though a jdk 1.4 
compiler was required.
  
> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-3129) Create Demo code, showing how to create and use table functions.

[Rick Hillegas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-3129:
-

Attachment: derby-3129-sampleTableFunctions-ab.diff

Thanks for taking a look at this patch, John! I have attached a second rev, 
derby-3129-sampleTableFunctions-ab.diff. This patch makes some changes:

1) Splits the vtiDemo.sql script into two scripts. The first, demoFileVtis.sql, 
tests the file-based VTIs which don't depend on having a MySQL installation. 
The second script, demoForeignDbmsVtis.sql tests the machinery which depends on 
a MySQL installation.

2) Thanks for catching the lingering reference to a relative path in the first 
script. I have fixed this.

3) Thanks for pointing out that the MySQL database name was confusing. I have 
changed the second script to expect that the database will be named "world" as 
you recommended.

4) I added a bit more verbiage to the README file.


> Create Demo code, showing how to create and use table functions.
> 
>
> Key: DERBY-3129
> URL: https://issues.apache.org/jira/browse/DERBY-3129
> Project: Derby
>  Issue Type: Improvement
>  Components: Demos/Scripts
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3129-sampleTableFunctions-aa.diff, 
> derby-3129-sampleTableFunctions-ab.diff
>
>
> Create some useful, sample table functions.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3095) CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS

[EDAH-TALLY (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535752
 ] 

EDAH-TALLY commented on DERBY-3095:
---

<>Note that the delimited identifier "EVE" represents the user EVE which is the 
same user as the regular identifiers eve, EVE and EvE

I didn't take this point into consideration, I therefore have to rethink the 
problem partly. It seems quite strange however and not really logical. It seems 
like saying "just pull the quotes and you're anyone else" !

During user deletion, the full user list is retrieved by 
SYSCS_GET_DATABASE_PROPERTY.  It behaves simply : 

"eve" is retrieved as "eve"
"EVE" as "EVE"
"EvE" as "EvE"
eve as eve 
EVE as EVE
Eve as Eve ...

<>Is that what your patch does?
It does essentially 2 things : 
1. It prevents a quoted identifier to lose its quotes by a call to 
parseQId(...) from parseId(StringReader r, boolean normalize, boolean 
normalizeToUpper)
2. It applies parsing and transformation to an application supplied identifier 
[ id in deleteId(String id, String list) ] .

<>I can't really tell the behaviour you are trying to achieve
I am trying to preserve a quoted identifier as quoted. If it loses its quotes, 
it is no longer the same user and can be anyone.
Secondly, I think the identifier passed in by an app should be parsed the same 
way as individual users retrieved from an accesslist.




> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> 
>
> Key: DERBY-3095
> URL: https://issues.apache.org/jira/browse/DERBY-3095
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.3.1.4
> Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
>Reporter: EDAH-TALLY
> Attachments: 3095_00.diff, 3095_01.diff, d3095.sql, 
> REGTEST3095_00.zip, REGTEST3095_01.zip, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the 
> stack trace : 
> **
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
> at 
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.execute(Unknown 
> Source)
> at com.somecom.createUser(someAPP.java:190)
> at com.somecom.grantKeys(someAPP.java:288)
> at com.somecom.showGrantKeys(someAPP.java:269)
> at com.somecom.MDIMenuClicked(someAPP.java:620)
> at com.somecom.access$000(someAPP.java:15)
> at com.somecom$5.actionPerformed(someAPP.java:564)
> at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
> at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
> at java.awt.Component.processMouseEvent(Component.java:6038)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
> at java.awt.Component.processEvent(Component.java:5803)
> at java.awt.Container.processEvent(Container.java:2058)
> at java.awt.Component.dispatchEventImpl(Component.java:4410)
> at java.awt.Container.dispatchEventImpl(Container.java:2116)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
> at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
> at java.awt.Container.dispatchEventImpl(Container.java:2102)
> at java.awt.Window.dispatchEventImpl(Window.java:2429)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at java.awt.EventQueue.dispatchEvent(EventQueue.java:599)
> at 
> java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
> at 
> java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
> at 
> java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
> at 
> java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.ja

[jira] Commented: (DERBY-3117) Adjust master build script to require the Java 5 compiler to build Derby

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535738
 ] 

Rick Hillegas commented on DERBY-3117:
--

Thanks. In that case I agree that option (2) is brittle and (1) is better. Not 
foolproof, though. Someone could still set java15compile.classpath to be the 
Java 6 classpath.

I wonder if we should further reduce the brittleness by requiring that the 
compiler level be exactly Java 5. This could be enforced by the build script.

> Adjust master build script to require the Java 5 compiler to build Derby
> 
>
> Key: DERBY-3117
> URL: https://issues.apache.org/jira/browse/DERBY-3117
> Project: Derby
>  Issue Type: Improvement
>  Components: Build tools
>Affects Versions: 10.4.0.0
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-3117-01-enforceJava5-aa.diff, 
> derby-3117-01-enforceJava5-ab.diff, derby-3117-01-enforceJava5-ac.diff, 
> derby-3117-02-website-aa.diff, derby_source.html
>
>
> Require the Java 5 compiler in order to build Derby as approved by the 
> community recently: 
> http://www.nabble.com/-VOTE--Require-Java-5-%28or-later%29-compiler-to-build-Derby-tf4522491.html#a13030783

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-716) Re-enable VTIs

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535757
 ] 

Rick Hillegas commented on DERBY-716:
-

Committed derby-716-10-datatypesCollation-aa.diff at subversion revision 585710.

> Re-enable VTIs
> --
>
> Key: DERBY-716
> URL: https://issues.apache.org/jira/browse/DERBY-716
> Project: Derby
>  Issue Type: New Feature
>  Components: SQL
>Reporter: Rick Hillegas
>Assignee: Rick Hillegas
> Attachments: derby-716-01-basic-aa.diff, 
> derby-716-02-DatabaseMetaData-aa.diff, derby-716-03-DatabaseMetaData-aa.diff, 
> derby-716-04-Optimizer-aa.diff, derby-716-05-PublicAPI-aa.diff, 
> derby-716-06-TestEncoding-aa.diff, derby-716-07-dblook-aa.diff, 
> derby-716-08-upgrade-aa.diff, derby-716-09-upgradeLocalization-aa.diff, 
> derby-716-10-datatypesCollation-aa.diff, functionTables.html, 
> functionTables.html, functionTables.html
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-857) LDAP user authentication fails under a security manager

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535760
 ] 

Kathey Marsden commented on DERBY-857:
--

Investigating this further I find that I need to give the permission to the top 
level program, for example if I use ij to connect I need to give the 
SocketPermission to derbytools.jar.  If I write a small program to connect. I 
need to give that program permission. e.g.

grant codeBase "file:c:/kmarsden/repro/DERBY-857/-" {
  permission java.net.SocketPermission "", "resolve,connect";   

};

> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
> Attachments: derby-857_diff.txt
>
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException: 
> > noSuchMachine:389 [Root exception is java.security.AccessControlException: 
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv 
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DERBY-2212) Add "Unique where not null" to create index

[Mike Matrigali (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Matrigali updated DERBY-2212:
--


I continue to think that it is a bad idea to introduce duplicate values to the 
current btree unique index (and sorting paradigm).  I guess you are building a 
"mostly" uniquei index.  I understand that SQL wants to treat the nulls 
differently but the basic assumptions of a lot of the structure of the unique 
btree (splitting, searching, logical recovery, branch node keys, 
serializable locking, ) all are based on actual lower level physical nature 
of the keys.  

For instance while the SQL layer may never do a search where key=null, the 
logical recovery code may execute a search on the unique index using the key 
expecting null to
match null.   So if index
is a single column unique index, with say 1,000,000 null values we may issue a 
search
in the unique index for "null" assuming we will find the single row because it 
is a unique
index.  I believe the current search algorithm is optimized for unique indexes 
to not include
the row location column in the search comparisons.

 Introducing duplicate nulls to unique indexes I believe will unnecessarily 
complicate the code and likely introduce bugs which will be hard to identify in 
the future.

Safest would be to use existing non-unique indexes with extra work by language 
layer to 
verify uniqueness at insert time (indexes don't support updates so they default 
to a delete and
insert -- thus just one path to code/check).  It may be worth fiddling with the 
optimizer to recognize that this index is a "mostly unique non-unique index" so 
that it can get estimates better than a regular non-unique index.  

Adding support to the btree itself to perform the check at insert time is more 
efficient at the cost of complicating the btree code, but I think could be 
isolated to a single compare call at point just before value is about to be 
inserted into tree.  

I know it is enticing to use the unique tree, but just sometimes treat nulls as 
not equal and sometimes as equal - but i don't think that is the right approach.

> Add "Unique where not null" to create index
> ---
>
> Key: DERBY-2212
> URL: https://issues.apache.org/jira/browse/DERBY-2212
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.2.1.6
>Reporter: Oleksandr Alesinskyy
>Assignee: Anurag Shekhar
> Attachments: derby-2212preview.diff, derby-2212preview2.diff
>
>
> Derby prohibits creation of unique constraints on nullable colums (as well if 
> only some columns in the constraint list are nullable) and treat nulls in 
> unique indexes as normal values (i.e. only one row with null values in 
> indexed columns may be inserted into the table). This bahavior is very 
> restrictive, does not completely comply with SQL standards (both letter and 
> intent) as well as with business needs and intending meaning of NULL values 
> (2 null values are not considered as equal, this comparision shall return 
> NULL, and for selection criteria boolean null is treated as FALSE).
> This behavior, as far as I can see, is modelled after DB2 (and differs from 
> behavior of most other major databases, like SyBase, Oracle, etc.).
> But even DB2 provide some means to alleviate these restrictions, namely 
> "UNIQUE WHERE NOT NULL" clause for CREATE INDEX statement.
> It will be very good if such "UNIQUE WHERE NOT NULL" clause will be 
> introduced in Derby.
> Regards,
> Oleksandr Alesinskyy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3126) Inserting BigDecimal value in PreparedStatement with setBigDecimal into double column loses fractional digits

[Kathey Marsden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden closed DERBY-3126.
-

Assignee: Kathey Marsden

> Inserting BigDecimal value in PreparedStatement with setBigDecimal into 
> double column loses fractional digits
> -
>
> Key: DERBY-3126
> URL: https://issues.apache.org/jira/browse/DERBY-3126
> Project: Derby
>  Issue Type: Sub-task
>  Components: JDBC, Network Client
>Reporter: Kathey Marsden
>Assignee: Kathey Marsden
> Fix For: 10.3.1.5, 10.4.0.0
>
> Attachments: derby-2073_diff.txt, derby-2073_diff.txt, 
> derby-2073_diff.txt, derby-2073_stat.txt, derby-2073_stat.txt
>
>
> Splitting this issue into two subtasks one for setBigDecimal and one for 
> setObject as they take a different code path and I plan to submit separate 
> patches. Reproduces with BigDecimalProblemTester attached to DERBY-2073

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (DERBY-3127) Inserting BigDecimal value in PreparedStatement with setObject into double column loses fractional digits

[Kathey Marsden (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kathey Marsden closed DERBY-3127.
-


>  Inserting BigDecimal value in PreparedStatement with setObject into double 
> column loses fractional digits
> --
>
> Key: DERBY-3127
> URL: https://issues.apache.org/jira/browse/DERBY-3127
> Project: Derby
>  Issue Type: Sub-task
>  Components: JDBC, Network Client
>Reporter: Kathey Marsden
> Attachments: BigDecimalProblemTester.java, 
> BigDecimalProblemTester.java
>
>
> Split DERBY-2073 into two issues. This one for setObject as it follows a 
> different code path than setBigDecimal and I plan to submit two patches. See 
> Attached BigDecimalProblemTester for repro with setObject.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-3095) CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535769
 ] 

Daniel John Debrunner commented on DERBY-3095:
--

> <>Note that the delimited identifier "EVE" represents the user EVE which is 
> the same user as the regular identifiers eve, EVE and EvE

> I didn't take this point into consideration, I therefore have to rethink the 
> problem partly. It seems quite strange however and not really logical. It 
> seems like saying "just pull the quotes and you're anyone else" ! 

I think you are misunderstanding what I'm writing. 

User name EVE when represented as a SQL identifier can be any of: "EVE", EVE, 
eve, eVe (etc.). This is a single user with multiple ways to represent its 
value. It's the defined way that SQL works.

User name eve when represented as a SQL identifier can only be "eve"
User name eVe when represented as a SQL identifier can only be "eVe"
etc.

> Secondly, I think the identifier passed in by an app should be parsed the 
> same way as individual users retrieved from an accesslist. 

I dont think that's correct. There are different domains where the 
representation of a user name takes a different form. An application has to 
understand that and pass in the appropriate form. Like the CURRENT USER 
example, an application might also take a user name from 
DatabaseMetaData.getUser() and pass that into a SQL routine, in which case no 
quotes will exist, the user name will be in its normal form (see the just added 
wiki page).

For these routine it's important to note that the format of the user name being 
passed in does not match the format of the user name when set as a value of the 
associated Derby properties, the routine needs to correctly handle the 
conversion between them (which it isn't doing at the moment).

> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, null) FAILS
> 
>
> Key: DERBY-3095
> URL: https://issues.apache.org/jira/browse/DERBY-3095
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, Network Client
>Affects Versions: 10.3.1.4
> Environment: Linux 2.6.17-13mdv #1 SMP Fri Mar 23 15:18:36 EDT 2007 
> x86_64 AMD Athlon(tm) 64 Processor 3000+ GNU/Linux
>Reporter: EDAH-TALLY
> Attachments: 3095_00.diff, 3095_01.diff, d3095.sql, 
> REGTEST3095_00.zip, REGTEST3095_01.zip, Reproduce3095.zip
>
>
> Sorry to bother you again.
> CALL SYSCS_UTIL.SYSCS_SET_USER_ACCESS(?, 'NOACCESS') FAILS and here's the 
> stack trace : 
> **
> java.sql.SQLException: Droit d'accès 'NOACCESS' inconnu.
> at 
> org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
> at org.apache.derby.client.am.PreparedStatement.execute(Unknown 
> Source)
> at com.somecom.createUser(someAPP.java:190)
> at com.somecom.grantKeys(someAPP.java:288)
> at com.somecom.showGrantKeys(someAPP.java:269)
> at com.somecom.MDIMenuClicked(someAPP.java:620)
> at com.somecom.access$000(someAPP.java:15)
> at com.somecom$5.actionPerformed(someAPP.java:564)
> at 
> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> at 
> javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
> at 
> javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
> at 
> javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
> at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:1216)
> at 
> javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:1257)
> at java.awt.Component.processMouseEvent(Component.java:6038)
> at javax.swing.JComponent.processMouseEvent(JComponent.java:3260)
> at java.awt.Component.processEvent(Component.java:5803)
> at java.awt.Container.processEvent(Container.java:2058)
> at java.awt.Component.dispatchEventImpl(Component.java:4410)
> at java.awt.Container.dispatchEventImpl(Container.java:2116)
> at java.awt.Component.dispatchEvent(Component.java:4240)
> at 
> java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4322)
> at 
> java.awt.LightweightDispatcher.processMouseEvent(Container.java:3986)
> at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3916)
> at java.awt.Container.dispatchEventImpl(Container.java:2102)
> at java.awt.Window.dispatchEventImpl(Window.java:2429)
> at java.awt.Component.dispatchEvent(Component.java:4240)
>   

[jira] Commented: (DERBY-857) LDAP user authentication fails under a security manager

[Daniel John Debrunner (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535770
 ] 

Daniel John Debrunner commented on DERBY-857:
-

That's usually an indication that you are missing a priv block.
The last stack trace above (dated 10/17 10:20)  shows no priv block, thus I 
would expect a SecuityException,
but the previous comment says that adding a priv block makes no difference. Do 
you have the stack trace when that it is the case?

> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
> Attachments: derby-857_diff.txt
>
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException: 
> > noSuchMachine:389 [Root exception is java.security.AccessControlException: 
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv 
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Making Derby a top level Apache project

[Laura Stewart]

On 10/17/07, Rick Hillegas <[EMAIL PROTECTED]> wrote:
> Recently, the DB PMC discussed whether we should make Derby a top level
> Apache project. The consensus seemed to be that a) Derby is mature
> enough to be a top level project, b) no-one felt passionately one way or
> another, c) therefore this decision should be left to the Derby
> community. It seemed to me that the major argument for promoting Derby
> to be a top level project was
>
> + This would increase Derby's visibility.
>
> The major argument against promoting Derby to the top level was
>
> - This would force us to rototill our website.
>
> What do you think? Should we move Derby to the top level?
>

What sort of "rototilling" are we talking about for the Web site Rick?
Are there guidelines that will help us comply with the changes that
are necessary?

-- 
Laura Stewart

[jira] Updated: (DERBY-2212) Add "Unique where not null" to create index

[Mike Matrigali (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Matrigali updated DERBY-2212:
--


Also is there some sort of functional spec for this.  The initial description 
seems to indicate that you will provide some extra syntax to allow the creation 
of unique indexes which allow nulls, is that still the case?   I didn't see any 
parser changes, but again understand that this is a preview patch.

Also what is the intent of the change on existing indexes?  


> Add "Unique where not null" to create index
> ---
>
> Key: DERBY-2212
> URL: https://issues.apache.org/jira/browse/DERBY-2212
> Project: Derby
>  Issue Type: Improvement
>  Components: SQL
>Affects Versions: 10.2.1.6
>Reporter: Oleksandr Alesinskyy
>Assignee: Anurag Shekhar
> Attachments: derby-2212preview.diff, derby-2212preview2.diff
>
>
> Derby prohibits creation of unique constraints on nullable colums (as well if 
> only some columns in the constraint list are nullable) and treat nulls in 
> unique indexes as normal values (i.e. only one row with null values in 
> indexed columns may be inserted into the table). This bahavior is very 
> restrictive, does not completely comply with SQL standards (both letter and 
> intent) as well as with business needs and intending meaning of NULL values 
> (2 null values are not considered as equal, this comparision shall return 
> NULL, and for selection criteria boolean null is treated as FALSE).
> This behavior, as far as I can see, is modelled after DB2 (and differs from 
> behavior of most other major databases, like SyBase, Oracle, etc.).
> But even DB2 provide some means to alleviate these restrictions, namely 
> "UNIQUE WHERE NOT NULL" clause for CREATE INDEX statement.
> It will be very good if such "UNIQUE WHERE NOT NULL" clause will be 
> introduced in Derby.
> Regards,
> Oleksandr Alesinskyy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535775
 ] 

Rick Hillegas commented on DERBY-1387:
--

Thanks for rev 7 of the patch, Bernt. A couple more comments:

1) MDatabase.checkTableConsistency() - If this method is going to
return a String rather than a boolean, then I wonder if the failure
case should just return the message from the exception--rather than
repackaging that message as a SQLException.

2) MDatabase.getProperty() - This method seems to map states
to strings as follows:

  SQLException -> silently swallowed and replaced with a default value
  Property not set -> default value
  Property is set -> its value
  Not connected to database -> the string "N/A"

I think that mapping the first two states to the same outcome may turn
out to be confusing.

3) MDatabase.getStorageTempDirectory() - What is the default returned
by this method? Is STORAGE_TEMP_DIRECTORY always supposed to be set?
If not, this method seems to return a misleading default.

4) DerbySystemMBean.setStoragePageSize() - I think that the conversion
of 4k, 8k, 16k, and 32k to stringified integers should happen before the initial
check for legal values. As it stands, I don't think the conversion
will ever be executed.



> Add JMX extensions to Derby
> ---
>
> Key: DERBY-1387
> URL: https://issues.apache.org/jira/browse/DERBY-1387
> Project: Derby
>  Issue Type: New Feature
>  Components: Services
>Reporter: Sanket Sharma
>Assignee: Bernt M. Johnsen
> Attachments: DERBY-1387-1.diff, DERBY-1387-1.stat, DERBY-1387-2.diff, 
> DERBY-1387-2.stat, DERBY-1387-3.diff, DERBY-1387-3.stat, DERBY-1387-4.diff, 
> DERBY-1387-4.stat, DERBY-1387-5.diff, DERBY-1387-5.stat, DERBY-1387-6.zip, 
> DERBY-1387-7.zip, derbyjmx.patch, jmx.diff, jmx.stat, jmxFuncspec.html, 
> Requirements for JMX Updated.html, Requirements for JMX.html, Requirements 
> for JMX.zip
>
>
> This is a draft requirement specification for adding monitoring and 
> management extensions to Apache Derby using JMX. The requirements document 
> has been uploaded on JIRA as well as the Derby Wiki page at 
> http://wiki.apache.org/db-derby/_Requirement_Specifications_for_Monitoring_%26_Management_Extensions_using_JMX
> Developers and Users are requested to please look at the document (feature 
> list in particular) and add their own rating to features by adding a coloumn 
> to the table.
> Comments are welcome.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Making Derby a top level Apache project

[Rick Hillegas]

Laura Stewart wrote:

On 10/17/07, Rick Hillegas <[EMAIL PROTECTED]> wrote:
  

Recently, the DB PMC discussed whether we should make Derby a top level
Apache project. The consensus seemed to be that a) Derby is mature
enough to be a top level project, b) no-one felt passionately one way or
another, c) therefore this decision should be left to the Derby
community. It seemed to me that the major argument for promoting Derby
to be a top level project was

+ This would increase Derby's visibility.

The major argument against promoting Derby to the top level was

- This would force us to rototill our website.

What do you think? Should we move Derby to the top level?




What sort of "rototilling" are we talking about for the Web site Rick?
Are there guidelines that will help us comply with the changes that
are necessary?

  

Hi Laura,

I haven't wrapped my head around this myself, yet. At a minimum I would 
expect some urls to change since we would be going from a 
db.apache.org/derby namespace to a derby.apache.org namespace. For the 
sake of external links back to Derby I would hope that the Apache site 
would be able to redirect the old urls--but I don't know that. I think 
that a detailed understanding of this could be provided by the folks who 
managed our graduation from the incubator namespace into the db namespace.


Regards,
-Rick

[jira] Commented: (DERBY-857) LDAP user authentication fails under a security manager

[Kathey Marsden (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535783
 ] 

Kathey Marsden commented on DERBY-857:
--

Thanks Dan for your time in looking at this.  There was indeed another call to 
InitialDirContext where I missed putting a privilege block.  It all works fine 
now.  I will prepare a patch with the full fix.

Kathey



> LDAP user authentication fails under a security manager
> ---
>
> Key: DERBY-857
> URL: https://issues.apache.org/jira/browse/DERBY-857
> Project: Derby
>  Issue Type: Bug
>  Components: Security
>Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.2.1.6
>Reporter: Daniel John Debrunner
>Assignee: Kathey Marsden
> Attachments: derby-857_diff.txt
>
>
> Running the test jdbcapi/secureUsers1.sql with a security manager results in:
> > ERROR 08004: Connection refused : javax.naming.CommunicationException: 
> > noSuchMachine:389 [Root exception is java.security.AccessControlException: 
> > access denied (java.net.SocketPermission noSuchMachine resolve)]
> Adding this permission to the policy file has no effect. which means a priv 
> block is required around the LDAP call.
> permission java.net.SocketPermission "noSuchMachine", "resolve";

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Making Derby a top level Apache project

[Daniel John Debrunner]

Rick Hillegas wrote:
Recently, the DB PMC discussed whether we should make Derby a top level 
Apache project. The consensus seemed to be that a) Derby is mature 
enough to be a top level project, b) no-one felt passionately one way or 
another, c) therefore this decision should be left to the Derby 
community. It seemed to me that the major argument for promoting Derby 
to be a top level project was


+ This would increase Derby's visibility.

The major argument against promoting Derby to the top level was

- This would force us to rototill our website.


Just to note that all of the above is Rick's opinion and not any 
official position of the DB-PMC.


I personally think there was at least one reason given that was more 
significant that updating the web-site. Since the discussions on DB-PMC 
are private I'll leave it to the individual who raised it there to raise 
it here if they so desire.


Dan.

[jira] Commented: (DERBY-1518) EmbedConnection prepareStatement(String, String[]) throws "not implemented" (JDBC 3.0)

[James F. Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-1518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535794
 ] 

James F. Adams commented on DERBY-1518:
---

This functionality appears to have been implemented by DERBY-2631.  If so this 
issue could be closed.

> EmbedConnection prepareStatement(String, String[]) throws "not implemented" 
> (JDBC 3.0)
> --
>
> Key: DERBY-1518
> URL: https://issues.apache.org/jira/browse/DERBY-1518
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.1.3.1
>Reporter: Brian Bonner
>
> Are there any plans to implement this functionality?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Regression Test Report - tinderbox_trunk16 585711 - Sun DBTG

[Ole . Solberg]

[Auto-generated mail]

*tinderbox_trunk16* 585711/2007-10-17 23:42:16 CEST

Failed  TestsOK  Skip  Duration   Suite
---
*Jvm: 1.6*
  SunOS-5.10_i86pc-i386
0288288 088.17% derbyall
F:0,E:197099708 0   1058.58% 
org.apache.derbyTesting.functionTests.suites.All
  Details in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/Limited/testSummary-585711.html
 
  Attempted failure analysis in
  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/FailReports/585711_bySig.html
 
---

Changes in  
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/UpdateInfo/585711.txt 

( All results in http://dbtg.thresher.com/derby/test/ ) 

Re: Making Derby a top level Apache project

[Kathey Marsden]

Daniel John Debrunner wrote:

Rick Hillegas wrote:
Recently, the DB PMC discussed whether we should make Derby a top 
level Apache project. The consensus seemed to be that a) Derby is 
mature enough to be a top level project, b) no-one felt passionately 
one way or another, c) therefore this decision should be left to the 
Derby community. It seemed to me that the major argument for 
promoting Derby to be a top level project was


+ This would increase Derby's visibility.

The major argument against promoting Derby to the top level was

- This would force us to rototill our website.


Just to note that all of the above is Rick's opinion and not any 
official position of the DB-PMC.


I personally think there was at least one reason given that was more 
significant that updating the web-site. Since the discussions on 
DB-PMC are private I'll leave it to the individual who raised it there 
to raise it here if they so desire.


This was my comment to the DB-PMC, in case that was the comment Dan was 
referring to.


"I would just like to say that I kind of like being part of the DB 
project.  While we do have quite a few active committers and PMC 
members, we do not have a particularly diverse group in terms of company 
affiliation. Being part of DB helps mitigate that."


Kathey

Re: Question on derby benchmarks.

[John Sisson]

It appears that it should go through the IP Clearance process that you 
mentioned.  AFAIK IBM had to go through the same process for the Derby 
network server tests, see the see the derby-2248-contribution-tests-ibm 
 
link on the IP clearance page.


The Derby PMC would be responsible for filing an IP clearance form.

Regards,
John

[EMAIL PROTECTED] wrote:

Daniel John Debrunner <[EMAIL PROTECTED]> writes:

  

Paulo Jesus wrote:


I have developed some code on engine of Derby ver 10.2.2. Is part of
larger project GAPI from GORDA project,  (support for replication
services),  that uses embedded code. The project was not ported to ver
10.3 yet.
I putted these question on list Derby-users but, after short talk
here,  i think maybe is best here.
I wonder what benchmarks have been in use by the Derby team. TPC-B?
And were can i find the source of those tests.
  

Olav from Sun seems to have a TPC-B like benchmark using Derby but I
don't believe the source is available.

http://wiki.apache.org/apachecon-data/attachments/Us2005OnlineSessionSlides/attachments/ApacheCon05usDerbyPerformance.pdf



I'm happy to announce that Sun has decided to donate the tests used by
Olav to the ASF and Derby. 


We are, however, a bit unsure about how to proceed. Can we simply
attach the files to a Jira issue and check the "Grant license to ASF for
inclusion in ASF works (as per the Apache License §5)" checkbox, or do
we need to to go through IP clearance
(http://incubator.apache.org/ip-clearance/index.html), for this
contribution? 


There are 3 tests (single record load, tpcb-like load and join load)
consisting of 27 source files that make up about 7000 lines of code
(wc -l).

Any advice would be much appreciated.

Thanks,