[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986365#action_12986365
]
Knut Anders Hatlen commented on DERBY-4741:
-------------------------------------------
The use of the static field thisTest may have some consequences that are not
entirely obvious:
The field is set when the test suite is created, so when the tests start
running it will always point to the last test case that was created, not
necessarily to the running test case. That is, it will always point to a client
test case. Because of this, one may be led to believe that the test that calls
thisTest.openDefaultConnection() always uses client connections. However,
BaseJDBCTestCase.openDefaultConnection() calls TestConfiguration.getCurrent()
to get the current test configuration, so the connection type should be chosen
dynamically based on the active decorators. But this assumption is also not
quite true. The decorators only affect the TestConfiguration for the main
thread, so when running inside a stored procedure in a server thread, the
decorators will have no effect, and an embedded connection will be opened even
if the test case is actually running within a client/server decorator.
I think the intention is to always use embedded connections inside the stored
procedure, and that's also what the code does (so, as mentioned in an earlier
comment, there's probably not much point in running this test in client/server
mode?). But it takes some effort to convince oneself that that's what it
actually does. Do you think it's possible to make it more explicit that the
worker threads always use embedded connections?
And some little nits:
+ if (w.e != null) {
+ fail("WorkerThread " + i + " saw exception " + w.e);
+ }
Use the fail() method that takes an exception to preserve the stack trace?
+ ResultSet rs = s.executeQuery("select count(*) from mtTab");
+ rs.next();
+ assertEquals("too few rows inserted",
+ rs.getLong(1), NO_OF_THREADS * NO_OF_MT_OPS);
+ rs.close();
How do you know it must be too few and not too many? ;)
JDBC.assertSingleValueResultSet() could simplify this code.
> Make Derby work reliably in the presence of thread interrupts
> -------------------------------------------------------------
>
> Key: DERBY-4741
> URL: https://issues.apache.org/jira/browse/DERBY-4741
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0,
> 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0
> Reporter: Dag H. Wanvik
> Assignee: Dag H. Wanvik
> Attachments: derby-4741-a-01-api-interruptstatus.diff,
> derby-4741-a-01-api-interruptstatus.stat,
> derby-4741-a-02-api-interruptstatus.diff,
> derby-4741-a-02-api-interruptstatus.stat,
> derby-4741-a-03-api-interruptstatus.diff,
> derby-4741-a-03-api-interruptstatus.stat,
> derby-4741-a-04-api-interruptstatus.diff,
> derby-4741-a-04-api-interruptstatus.stat,
> derby-4741-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.stat,
> derby-4741-b-01-nio.diff, derby-4741-b-01-nio.stat, derby-4741-b-02-nio.diff,
> derby-4741-b-02-nio.stat, derby-4741-b-03-nio.diff, derby-4741-b-03-nio.stat,
> derby-4741-b-04-nio.diff, derby-4741-b-04-nio.stat, derby-4741-c-01-nio.diff,
> derby-4741-c-01-nio.stat, derby-4741-kristians-01.diff,
> derby-4741-nio-container+log+waits+locks+throws.diff,
> derby-4741-nio-container+log+waits+locks+throws.stat,
> derby-4741-nio-container+log+waits+locks-2.diff,
> derby-4741-nio-container+log+waits+locks-2.stat,
> derby-4741-nio-container+log+waits+locks.diff,
> derby-4741-nio-container+log+waits+locks.stat,
> derby-4741-nio-container+log+waits.diff,
> derby-4741-nio-container+log+waits.stat, derby-4741-nio-container+log.diff,
> derby-4741-nio-container+log.stat, derby-4741-nio-container-2.diff,
> derby-4741-nio-container-2.log, derby-4741-nio-container-2.stat,
> derby-4741-nio-container-2b.diff, derby-4741-nio-container-2b.stat,
> derby-4741-raf-stresstest-1.diff, derby-4741-raf-stresstest-1.stat,
> derby-4741-sleeps-waits-1.diff, derby-4741-sleeps-waits-1.stat,
> derby-4741-sleeps-waits-2.diff, derby-4741-sleeps-waits-2.stat,
> derby-4741-sleeps-waits-3.diff, derby-4741-sleeps-waits-3.stat, derby.log,
> derby.log, InterruptResilienceTest.java, MicroAPITest.java, xsbt0.log.gz
>
>
> When not executing on a small device VM, Derby has been using the Java NIO
> classes java.nio.clannel.* for file io.
> If thread is interrupted while executing blocking IO operations in NIO, the
> ClosedByInterruptException will get thrown. Unfortunately, Derby isn't
> current architected to retry and complete such operations (before passing on
> the interrupt), so the Derby database can be left in an inconsistent state
> and we therefore have to return a database level error. This means the
> applications can no longer access the database without a shutdown and reboot
> including a recovery.
> It would be nice if Derby could somehow detect and finish IO operations
> underway when thread interrupts happen before passing the exception on to the
> application. Derby embedded is sometimes embedded in applications that use
> Thread.interrupt to stop threads.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
