db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2492) convert checkDataSource, checkDataSource30 and checkDriver.java to junit
Date Fri, 06 Apr 2007 08:11:32 GMT

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

Myrna van Lunteren commented on DERBY-2492:

I just committed the first version of the converted test for checkDataSource and checkDataSource30:
DataSourceTest.java with revision 526087.
Also temporarily added a method to SecurityCheck.java, which will be replacing the similar
inspect method when I remove checkDataSource*. 
The only place where SecurityCheck is actually used, is in the checkDataSource tests, as far
as I could see. ResultSetMiscTest loads the class, but doesn't actually call any methods,
or so it seems to me).

There are some things left to do with this test, marked with '// TODO:' 

- the fixtures testGlobalLocalInterleaf() and testReuseAcrossGlobalLocal() leave the system
  in a locked state - with embedded, shutting down the database and reconnecting release the
  locks, but with Network Server / DerbyNetClient that action results in a DRDA_Protocol 
  error for testGlobalLocalInterleaf, and another, severe, protocol error for testReuse...
  This is not new - I've had trouble before running checkDataSource* with remote server, because
  of the bad state the test leaves the database in.

  I think there might be a bug somewhere, because even though all statements, preparedstatements,
  connections, resources, have been closed, the locks are stell held. Or I could just be missing

  Hopefully someone else can have a look and identify the problem.
  I will log a separate bug for it, for I don't think fixing this need be part of the conversion

  In the meantime, these two tests do not run with DerbyNetClient.

- there are some other differences between Network Server/ DerbyNetClient and embedded that
I need to find out/check if they are known bugs, or need to log new bugs for and hang off
the bug for differences (DERBY-310). The differences were present in the original masters
for DerbyNetClient, so there  *should* be bugs, or the behavior *should* be documented.

   these differences are:
     1. testAllDataSources(), through assertConnectionOK() and testReuseAcrossGlobalLocal()
through queryOnStatement(), returns a different connection when comparing a connection obtained
from a ConnectionPoolDataSource or an XADataSource, and Statement.getConnection() on a statement
created by doing Connection.createStatement().
        Note, that currently, testReuseAcrossGlobalLocal has been switched off for NetworkServer,
but I first added a if(usingEmbedded()) block to ignore this difference in both places where
I saw this diff pop up.

     2. There is a difference in the ReadOnly value returned in testGlobalLocalInterleaf()
in the XATransaction after setting ReadOnly. NetworkServer appears to not listen, Embedded
has the changed value.

     3. In testReuseAcrossGlobalLocal() when testing on a closed XAConnection, xac2.getXAResource()
does not return an error with NetworkServer, but does with Embedded.
     4. testXAHoldability(), when testing holdability of a statement created with holdability
true, outside the global transaction, the holdability inside global transaction is different.

- Finally, the setUp() and tearDown() methods are a little inelegant and probably could be

> convert checkDataSource, checkDataSource30 and checkDriver.java to junit
> ------------------------------------------------------------------------
>                 Key: DERBY-2492
>                 URL: https://issues.apache.org/jira/browse/DERBY-2492
>             Project: Derby
>          Issue Type: Test
>    Affects Versions:
>            Reporter: Myrna van Lunteren
>         Assigned To: Myrna van Lunteren

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

View raw message