Issue Details (XML | Word | Printable)

Key: DERBY-235
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Minor Minor
Assignee: Suresh Thalamati
Reporter: Suresh Thalamati
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Derby

unable to create a database using a different storage factory than the one provided by default with the engine

Created: 26/Apr/05 10:24 AM   Updated: 07/Jun/05 08:56 AM
Return to search
Component/s: Services
Affects Version/s: 10.1.1.0
Fix Version/s: 10.1.1.0

Time Tracking:
Not Specified

Environment: Windows , jdk142

Resolution Date: 03/May/05 05:32 AM


 Description  « Hide
java -Dderby.subSubProtocol.csf=org.apache.derbyTesting.functionTests.util.corruptio.CorruptDiskStorageFactory org.apache.derby.tools.ij
ij> connect 'jdbc:derby:csf:wombat1;create=true';
ERROR XJ001: Java exception: 'ASSERT FAILED mismatched canonical names csf:C:\suresht\databases\wombat1 != C:\suresht\databases\wombat1: org.apache.derby.iapi.s
ervices.sanity.AssertFailure'.
Stack :
============= begin nested exception, level (1) ===========
org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT FAILED mismatched canonical names csf:C:\suresht\databases\wombat1 != C:\suresht\databases\wombat1
       at org.apache.derby.iapi.services.sanity.SanityManager.ASSERT(SanityManager.java:121)
       at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1773)
       at org.apache.derby.impl.services.monitor.BaseMonitor.createPersistentService(BaseMonitor.java:1018)
       at org.apache.derby.iapi.services.monitor.Monitor.createPersistentService(Monitor.java:578)
       at org.apache.derby.impl.jdbc.EmbedConnection.createDatabase(EmbedConnection.java:1509)
       at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:220)
       at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:72)
       at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:73)
       at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:183)
       at java.sql.DriverManager.getConnection(DriverManager.java:512)
       at java.sql.DriverManager.getConnection(DriverManager.java:140)
       at org.apache.derby.impl.tools.ij.ij.dynamicConnection(ij.java:838)
       at org.apache.derby.impl.tools.ij.ij.ConnectStatement(ij.java:700)
       at org.apache.derby.impl.tools.ij.ij.ijStatement(ij.java:528)
       at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:289)
       at org.apache.derby.impl.tools.ij.Main.go(Main.java:209)
       at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:175)
       at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
       at org.apache.derby.tools.ij.main(ij.java:60)
============= end nested exception, level (1) ===========
Cleanup action completed
--

By Briefly looking the code what I found:
getCanonicalServiceName() calls return the service name add sub protocol name
(eg : csf) in the beginning like csf:C:\suresht\databases\wombat1 . Where as
createServiceRoot(..) return canonical name without the protocol like
C:\suresht\databases\wombat1.

Related code:
org.apache.derby.impl.services.monitor.BaseMonitor.java
bootService(..)
{...

if(create){
...
serviceName = provider.createServiceRoot(serviceName,
Boolean.valueOf(properties.getProperty(Property.DELETE_ON_CREATE)).booleanValue());

}
SanityManager.ASSERT(provider.getCanonicalServiceName(serviceName).equals(serviceName),
"mismatched canonical names provider.getCanonicalServiceName(serviceName)
+ " != " + serviceName);
--

getCanonicalServiceName() calls return the service name add sub protocol name
(eg : csf) in the beginning like csf:C:\suresht\databases\wombat1 . Where as
createServiceRoot(..) return canonical name without the protocol like
C:\suresht\databases\wombat1.


One thing I could not understand is why service name is reset to the value that is returned from the createServiceRoot(..) ? Is it expected to be different
than the one that is passed to it in some scenario ?

 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Repository Revision Date User Message
ASF #165645 Mon May 02 15:51:48 UTC 2005 mikem committing this patch for DERBY-235 for suresh.thalamati@gmail.com

Problem was service name on database creation was getting just set to the canonical name of the database directory
without subsub protocol name added in the beginning. Whereas rest of the system seems to expect that the
subsub protocol name also is part of the service name. For example if "csf" is subprotocol name ,
service name should be "csf:C:\suresht\databases\wombat1" not just "C:\suresht\databases\wombat1".
Attached diff fixes the problem by prefixing the subsub protocol name to the canonical name, to generate
the service name in the case of create also.

This was not an issue with default "directory" subsub protocol because the system consistently generates
the service name as just the canonical name of the service root.

Another doubt I had while fixing this issue why we generate the service name after creating the service root,
my guess is because of the following comment in the java docs for java.io.File.getCanonicalPath() method:
" Every pathname that denotes an existing file or directory has a unique canonical form. Every pathname that
denotes a nonexistent file or directory also has a unique canonical form. The canonical form of the pathname of a
nonexistent file or directory may be different from the canonical form of the same pathname after the file or
directory is created. Similarly, the canonical form of the pathname of an existing file or directory may be different from the
canonical form of the same pathname after the file or directory is deleted.
"
Files Changed
MODIFY /incubator/derby/code/trunk/java/engine/org/apache/derby/impl/services/monitor/PersistentServiceImpl.java


Powered by a free Atlassian JIRA open source license for Apache Software Foundation. Try JIRA - bug tracking software for your team.
Atlassian JIRA the Professional Issue Tracker. (Enterprise Edition, Version: 3.13.2-#335) - Bug/feature request - Atlassian news - Contact Administrators