You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Myrna van Lunteren (JIRA)" <ji...@apache.org> on 2007/04/06 10:11:32 UTC

[jira] Commented: (DERBY-2492) convert checkDataSource, checkDataSource30 and checkDriver.java to junit

    [ 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
  something...

  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 effort.

  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 improved.


> 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: 10.3.0.0
>            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.