In recent days, a forkjoin thread has been reported to the database from the Druid connection:
2020-07-15 11:46:01.228 INFO [ForkJoinPool-1-worker-15]... Caused by: java.lang.NullPointerException:null
at com.alibaba.druid.pool.DruidPooledConnection.transactionRecord(DruidPooledConnection.java:720)
at com.alibaba.druid.pool.DruidPooledStatement.transactionRecord(DruidPooledStatement.java:284)
at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:491)
Copy the codeCheck out the source code:
// DruidPooledConnection.java:720
710 protected void transactionRecord(String sql) throws SQLException {
720 if (transactionInfo == null&& (! conn.getAutoCommit())) {721 DruidAbstractDataSource dataSource = holder.getDataSource();
722 dataSource.incrementStartTransactionCount();
723 transactionInfo = new TransactionInfo(dataSource.createTransactionId());
724}...Copy the codeThat is, conn is null, and conn is an instance of java.sql.Connection, a few lines back
// DruidPooledPreparedStatement.java:491
486 public int getMaxFieldSize(a) throws SQLException {
487 checkOpen();
488
489 try {
490 return stmt.getMaxFieldSize();
491 } catch (Throwable t) {
492 throw checkException(t);
493 }
494}...Copy the codeOpen ==false; open ==false
// DruidPooledPreparedStatement.java:491
protected void checkOpen(a) throws SQLException {
if (closed) {
Throwable disableError = null;
if (this.conn ! =null) {
disableError = this.conn.getDisableError();
}
if(disableError ! =null) {
throw new SQLException("statement is closed", disableError);
} else {
throw new SQLException("statement is closed"); }}}Copy the codeConn ==null throws an exception. Could conn be concurrent and its state be changed by another thread?
Then looking up the log, the database connection is brokered by the distributed transaction framework:
2020-07-15 11:46:01.215 DEBUG [ForkJoinPool-1-worker-15] com.codingapi.txlcn.tc.aspect.weave.DTXResourceWeaver - proxy a sql connection: com.codingapi.txlcn.tc.core.transaction.lcn.resource.LcnConnectionProxy@65907ef8.
Copy the codeIf there is a concurrency problem, is the connection being used by multiple threads, so then look for the keyword “65907EF8”,
2020-07-15 11:46:00.476 DEBUG [http-nio-20790-exec-39] com.codingapi.txlcn.tc.aspect.weave.DTXResourceWeaver - proxy a sql connection: com.codingapi.txlcn.tc.core.transaction.lcn.resource.LcnConnectionProxy@65907ef8.
......
2020-07-15 11:46:01.227 WARN [http-nio-20790-exec-39] com.codingapi.txlcn.tc.core.transaction.lcn.resource.LcnConnectionProxy - transaction type[lcn] proxy connection:com.codingapi.txlcn.tc.core.transaction.lcn.resource.LcnConnectionProxy@65907ef8 closed.
Copy the codeBy comparing the time, it can be found that the HTTP-NiO-20790-exec-39 thread, which processes the application request, opens the proxy connection for distributed transactions, and closes the connection after processing. In between, forkJoinPool-1-worker-15 connections are proided. Finally, after the HTTP connection is closed, the ForkJoin thread throws an exception. Why, then, does the HTTP thread share a database connection?
An exception occurred with the forkjoin thread:
// Execute the check concurrentlyforkJoinConfig.getForkJoinPool().submit(() -> { list.parallelStream().forEach(checker -> { checker.check(param, result); }); }).join();Copy the codeGetForkJoinPool () takes the forkJoin thread pool that we configured for the list’s foreach operations.
View tX-LCN source code, part of the database agent:
// com.codingapi.txlcn.tc.aspect.weave.DTXResourceWeaver
public Object getConnection(ConnectionCallback connectionCallback) throws Throwable {
DTXLocalContext dtxLocalContext = DTXLocalContext.cur();
if (Objects.nonNull(dtxLocalContext) && dtxLocalContext.isProxy()) {
String transactionType = dtxLocalContext.getTransactionType();
TransactionResourceProxy resourceProxy = txLcnBeanHelper.loadTransactionResourceProxy(transactionType);
Connection connection = resourceProxy.proxyConnection(connectionCallback);
log.debug("proxy a sql connection: {}.", connection);
return connection;
}
return connectionCallback.call();
}
Copy the codePresumably to get the transaction context and thus the proxy object for the database connection.
Forkjoin thread, log type “proxy a SQL Connection”, indicating dtxLocalContext! =null, what is DTXLocalContext?
// com.codingapi.txlcn.tc.core.DTXLocalContext
/** * gets the current thread variable. This method is not recommended, as it generates a NullPointerException * *@returnThe current thread variable */
public static DTXLocalContext cur(a) {
return currentLocal.get();
}
///
private final static ThreadLocal<DTXLocalContext> currentLocal = new InheritableThreadLocal<>();
Copy the codeSo the problem should be currentLocal, which is an instance of InheritableThreadLocal.
Get (ThreadLocal) allows you to retrieve objects stored by the current thread.
InheritableThreadLocal works similarly, except that when a child thread is initialized, it copies the parent thread’s map data.
// java.lang.Thread#init
if(inheritThreadLocals && parent.inheritableThreadLocals ! =null)
this.inheritableThreadLocals =
ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
Copy the codeInheritableThreadLocals is what we call the thread of the map, it is a ThreadLocal ThreadLocalMap instance.
In our example, the forkJoin thread is created by copying the data of the parent thread with a DTXLocalContext object, indicating that the forkJoinPool-1-worker-15 thread was created by http-NiO-20790-execut-39. That means the same forkJoin thread pool was used for HTTP thread execution (verified by code search).
conclusion
In order to track the concurrency in request Q1, we store the distributed transaction context, including the database connection, in the InheritableThreadLocal object, so that child thread A can obtain the distributed transaction context and obtain the same database connection later.
However, if subthread A is in the thread pool, and another request Q2 uses the thread pool and happens to be partitioned to thread A, then the same database connection is obtained. However, this database connection is controlled by request Q1, and Q2 is at risk of closing the database connection at any time.
Conversely, if a modification is made to request Q2, the accuracy of request Q1 may also be affected, i.e. the database connection is compromised for Q1.
How do distributed transaction contexts and thread pools coexist?Copy the codeDruid: 1.1.16tx-lcn: 6.0.20.RELEASE druid: 1.1.16tx-lcn: 6.0.20.RELEASECopy the codeBlog address: Wonderwater.github. IO /