After starting, access the following URL.
http://localhost:8080
If it starts normally, the following screen will be displayed.
If you click on the link labeled "Deadlock (SQL)" in it, you will see a screen where you can reproduce the deadlock (SQL).
Open this screen in another window (or tab) as written at the bottom of the screen. Click the user ID link once in one window to sort the user list by ID in descending order. Then, immediately after clicking the "Update" button, click the "Update" button in ascending order in another window.
After a while, one window will display the message "10 updated" and the other will display the message "The lock could not be acquired due to a deadlock." At this time, a deadlock has occurred in the RDBMS.
Let's check the log. Looking at logs / easybuggy.log, two threads (qtp1806431167-21, qtp1806431167-23) alternately update user information, the former updates USER04 and the latter updates USER05 for 20 seconds. A stop has occurred. After that, you can see that the latter continues processing and the former has a SQLTransactionRollbackException.
2017-04-24 13:21:26 INFO qtp1806431167-23 DeadlockServlet2 user09 is updated.
2017-04-24 13:21:26 INFO qtp1806431167-21 DeadlockServlet2 user00 is updated.
2017-04-24 13:21:26 INFO qtp1806431167-23 DeadlockServlet2 user08 is updated.
2017-04-24 13:21:26 INFO qtp1806431167-21 DeadlockServlet2 user01 is updated.
2017-04-24 13:21:27 INFO qtp1806431167-23 DeadlockServlet2 user07 is updated.
2017-04-24 13:21:27 INFO qtp1806431167-21 DeadlockServlet2 user02 is updated.
2017-04-24 13:21:27 INFO qtp1806431167-23 DeadlockServlet2 user06 is updated.
2017-04-24 13:21:27 INFO qtp1806431167-21 DeadlockServlet2 user03 is updated.
2017-04-24 13:21:28 INFO qtp1806431167-23 DeadlockServlet2 user05 is updated.
2017-04-24 13:21:28 INFO qtp1806431167-21 DeadlockServlet2 user04 is updated.
2017-04-24 13:21:48 INFO qtp1806431167-23 DeadlockServlet2 user04 is updated.
2017-04-24 13:21:48 ERROR qtp1806431167-21 DeadlockServlet2 SQLTransactionRollbackException occurs:
java.sql.SQLTransactionRollbackException: A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : ROW, USERS, (1,16)
Waiting XID : {198, X} , APP, Update users set name = ?, phone = ?, mail = ? where id = ?
Granted XID : {194, X}
Lock : ROW, USERS, (1,15)
Waiting XID : {194, X} , APP, Update users set name = ?, phone = ?, mail = ? where id = ?
Granted XID : {198, X}
. The selected victim is XID : 198.
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(Unknown Source)
at org.t246osslab.easybuggy.troubles.DeadlockServlet2.updateUsers(DeadlockServlet2.java:170)
at org.t246osslab.easybuggy.troubles.DeadlockServlet2.service(DeadlockServlet2.java:55)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
at org.t246osslab.easybuggy.core.filters.SecurityFilter.doFilter(SecurityFilter.java:51)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1495)
at org.t246osslab.easybuggy.core.filters.EncodingFilter.doFilter(EncodingFilter.java:42)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1495)
at org.t246osslab.easybuggy.core.filters.AuthenticationFilter.doFilter(AuthenticationFilter.java:72)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1487)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:984)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1045)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:236)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.sql.SQLException: A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : ROW, USERS, (1,16)
Waiting XID : {198, X} , APP, Update users set name = ?, phone = ?, mail = ? where id = ?
Granted XID : {194, X}
Lock : ROW, USERS, (1,15)
Waiting XID : {194, X} , APP, Update users set name = ?, phone = ?, mail = ? where id = ?
Granted XID : {198, X}
. The selected victim is XID : 198.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
... 42 more
Caused by: ERROR 40001: A lock could not be obtained due to a deadlock, cycle of locks and waiters is:
Lock : ROW, USERS, (1,16)
Waiting XID : {198, X} , APP, Update users set name = ?, phone = ?, mail = ? where id = ?
Granted XID : {194, X}
Lock : ROW, USERS, (1,15)
Waiting XID : {194, X} , APP, Update users set name = ?, phone = ?, mail = ? where id = ?
Granted XID : {198, X}
. The selected victim is XID : 198.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.services.locks.Deadlock.buildException(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(Unknown Source)
at org.apache.derby.impl.services.locks.AbstractPool.lockObject(Unknown Source)
at org.apache.derby.impl.services.locks.ConcurrentPool.lockObject(Unknown Source)
at org.apache.derby.impl.store.raw.xact.RowLocking3.lockRecordForWrite(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknown Source)
at org.apache.derby.impl.store.access.heap.HeapController.lockRow(Unknown Source)
at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3.lockRowOnPage(Unknown Source)
at org.apache.derby.impl.store.access.btree.index.B2IRowLocking3._lockScanRow(Unknown Source)
at org.apache.derby.impl.store.access.btree.index.B2IRowLockingRR.lockScanRow(Unknown Source)
at org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(Unknown Source)
at org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(Unknown Source)
at org.apache.derby.impl.sql.execute.TableScanResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.IndexRowToBaseRowResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(Unknown Source)
at org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(Unknown Source)
at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
... 36 more
2017-04-24 13:21:49 INFO qtp1806431167-23 DeadlockServlet2 user03 is updated.
2017-04-24 13:21:49 INFO qtp1806431167-23 DeadlockServlet2 user02 is updated.
2017-04-24 13:21:50 INFO qtp1806431167-23 DeadlockServlet2 user01 is updated.
2017-04-24 13:21:50 INFO qtp1806431167-23 DeadlockServlet2 user00 is updated.
What kind of implementation is it?
What kind of implementation was the source code? Look at DeadlockServlet2.java that was output to the log. Let's. The important parts are:
private String updateUsers(ArrayList<User> users, Locale locale) {
・ ・ ・(Abbreviation)・ ・ ・
try {
conn = DBClient.getConnection();
conn.setAutoCommit(false);
stmt = conn.prepareStatement("Update users set name = ?, phone = ?, mail = ? where id = ?");
for (User user : users) {
stmt.setString(1, user.getName());
stmt.setString(2, user.getPhone());
stmt.setString(3, user.getMail());
stmt.setString(4, user.getUserId());
executeUpdate = executeUpdate + stmt.executeUpdate();
Thread.sleep(500);
}
conn.commit();
resultMessage = MessageUtils.getMsg("msg.update.records", new Object[] { executeUpdate }, locale) + "<br><br>";
} catch (SQLTransactionRollbackException e) {
resultMessage = MessageUtils.getErrMsg("msg.deadlock.occurs", locale);
log.error("SQLTransactionRollbackException occurs: ", e);
rollbak(conn);
・ ・ ・(Abbreviation)・ ・ ・
}
In this Servlet, the user list data on the screen is acquired in order from the top, and the RDBMS user record is updated with the UPDATE statement. And I'm committed when all the updates are done.
When the first thread updates USER05 and then tries to update USER04, the second thread updates USER04, then tries to update USER05 and waits for each other to complete. .. DB (Derby) detects that a deadlock has occurred and returns an error to the transaction of the second thread after 20 seconds. On the other hand, the second thread catches SQLTransactionRollbackException and handles the exception.
What about other settings and databases?
The deadlock behavior also depends on the RDBMS used and the settings. The RDBMS used this time is a built-in Derby in "in-memory database" mode, and the default is row level lock (* To be precise, it is basically row level lock, and the lock granularity is adjusted in consideration of performance. Expands to multi-row locks and table locks).
Operation with table level lock
See the Derby Developer Guide (https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/devguide/index.html) for an option called derby.storage.rowLocking. You can turn a row-level lock into a table-level lock by setting it to false.
So, let's verify the operation of table level lock. Modify the following line in pom.xml.
<!-- <argument>-Dderby.storage.rowLocking=true</argument> -->
<!--Change the value in the top line from true to false-->
<argument>-Dderby.storage.rowLocking=false</argument>
Restart EasyBuggy and give it a try. mvn command (mvn clean install exec: exec
If it is started with), stop it with Ctrl + C and start it again with the same command. Then, update the two lists with the sort order reversed again. This time there should be no deadlock. If you check the log, the next thread is starting to update, waiting for the update of the first updated thread to be completed as shown below.
2017-04-24 13:51:50 INFO qtp1806431167-24 DeadlockServlet2 user09 is updated.
2017-04-24 13:51:50 INFO qtp1806431167-24 DeadlockServlet2 user08 is updated.
2017-04-24 13:51:51 INFO qtp1806431167-24 DeadlockServlet2 user07 is updated.
2017-04-24 13:51:51 INFO qtp1806431167-24 DeadlockServlet2 user06 is updated.
2017-04-24 13:51:52 INFO qtp1806431167-24 DeadlockServlet2 user05 is updated.
2017-04-24 13:51:52 INFO qtp1806431167-24 DeadlockServlet2 user04 is updated.
2017-04-24 13:51:53 INFO qtp1806431167-24 DeadlockServlet2 user03 is updated.
2017-04-24 13:51:53 INFO qtp1806431167-24 DeadlockServlet2 user02 is updated.
2017-04-24 13:51:54 INFO qtp1806431167-24 DeadlockServlet2 user01 is updated.
2017-04-24 13:51:54 INFO qtp1806431167-24 DeadlockServlet2 user00 is updated.
2017-04-24 13:51:55 INFO qtp1806431167-20 DeadlockServlet2 user00 is updated.
2017-04-24 13:51:56 INFO qtp1806431167-20 DeadlockServlet2 user01 is updated.
2017-04-24 13:51:56 INFO qtp1806431167-20 DeadlockServlet2 user02 is updated.
2017-04-24 13:51:57 INFO qtp1806431167-20 DeadlockServlet2 user03 is updated.
2017-04-24 13:51:57 INFO qtp1806431167-20 DeadlockServlet2 user04 is updated.
2017-04-24 13:51:58 INFO qtp1806431167-20 DeadlockServlet2 user05 is updated.
2017-04-24 13:51:58 INFO qtp1806431167-20 DeadlockServlet2 user06 is updated.
2017-04-24 13:51:59 INFO qtp1806431167-20 DeadlockServlet2 user07 is updated.
2017-04-24 13:51:59 INFO qtp1806431167-20 DeadlockServlet2 user08 is updated.
2017-04-24 13:52:00 INFO qtp1806431167-20 DeadlockServlet2 user09 is updated.
It's a table-level lock, so if you already have a transaction that has acquired the lock, you'll have to wait for it to complete. Since it is updated after completion, the update contents of the thread that was updated first will be overwritten.
Behavior in MySQL
I will also verify it with MySQL. Comment out the Derby setting in easybuggy / src / main / resources / application.properties and add the MySQL setting. The version of MySQL used this time is 5.1.73.
### RDBMS
#Comment out the Derby setting in in-memory DB mode and
#database.url=jdbc:derby:memory:demo;create=true
#database.driver=org.apache.derby.jdbc.EmbeddedDriver
#Add MySQL settings
database.url=jdbc:mysql://localhost:3306/easybuggy?user=easybuggy&password=password
database.driver=com.mysql.jdbc.Driver
The above setting is for connecting to the locally installed MySQL easybuggy database as a user named easybuggy, and the password for this user is password.
Now restart EasyBuggy and give it a try. Did a deadlock occur? It didn't happen in my environment. The reason lies in MySQL's default storage engine. If the MySQL version is earlier than 5.5, the default storage engine is "MyISAM".
$ mysql -u root
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 31
Server version: 5.1.73-log Source distribution
Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> use information_schema;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> select table_name, engine from tables where table_schema = 'easybuggy';
+------------+--------+
| table_name | engine |
+------------+--------+
| users | MyISAM |
+------------+--------+
1 row in set (0.00 sec)
MyISAM only supports table-level locking and does not support row-level locking. So edit /etc/my.cnf and change it to InnoDB.
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
symbolic-links=0
#Add the following
default-table-type=InnoDB
[mysqld_safe]
…
After making changes, restart MySQL and EasyBuggy and try again. I think a deadlock will occur this time.
2017-04-24 14:29:14 INFO qtp1806431167-22 DeadlockServlet2 user09 is updated.
2017-04-24 14:29:15 INFO qtp1806431167-22 DeadlockServlet2 user08 is updated.
2017-04-24 14:29:15 INFO qtp1806431167-25 DeadlockServlet2 user00 is updated.
2017-04-24 14:29:15 INFO qtp1806431167-22 DeadlockServlet2 user07 is updated.
2017-04-24 14:29:15 INFO qtp1806431167-25 DeadlockServlet2 user01 is updated.
2017-04-24 14:29:16 INFO qtp1806431167-22 DeadlockServlet2 user06 is updated.
2017-04-24 14:29:16 INFO qtp1806431167-25 DeadlockServlet2 user02 is updated.
2017-04-24 14:29:16 INFO qtp1806431167-22 DeadlockServlet2 user05 is updated.
2017-04-24 14:29:16 INFO qtp1806431167-25 DeadlockServlet2 user03 is updated.
2017-04-24 14:29:17 INFO qtp1806431167-22 DeadlockServlet2 user04 is updated.
2017-04-24 14:29:17 INFO qtp1806431167-22 DeadlockServlet2 user03 is updated.
2017-04-24 14:29:17 ERROR qtp1806431167-25 DeadlockServlet2 SQLTransactionRollbackException occurs:
com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
at com.mysql.jdbc.Util.getInstance(Util.java:386)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1066)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4187)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4119)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2570)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2731)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2815)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2155)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2458)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2375)
at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2359)
at org.t246osslab.easybuggy.troubles.DeadlockServlet2.updateUsers(DeadlockServlet2.java:169)
at org.t246osslab.easybuggy.troubles.DeadlockServlet2.service(DeadlockServlet2.java:57)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1507)
at org.t246osslab.easybuggy.core.filters.SecurityFilter.doFilter(SecurityFilter.java:51)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1495)
at org.t246osslab.easybuggy.core.filters.EncodingFilter.doFilter(EncodingFilter.java:42)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1495)
at org.t246osslab.easybuggy.core.filters.AuthenticationFilter.doFilter(AuthenticationFilter.java:72)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1487)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:427)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:370)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)
at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:984)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1045)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:236)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
2017-04-24 14:29:18 INFO qtp1806431167-22 DeadlockServlet2 user02 is updated.
2017-04-24 14:29:18 INFO qtp1806431167-22 DeadlockServlet2 user01 is updated.
2017-04-24 14:29:19 INFO qtp1806431167-22 DeadlockServlet2 user00 is updated.
When I checked the log, I was throwing a com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException that inherited java.sql.TransactionRollbackException.
Also, Derby took 20 seconds to detect the deadlock, but MySQL seemed to detect it immediately. This is thought to be due to differences in detection methods and algorithms. I haven't investigated it in detail, but I think it can be changed in the settings.
This summary
--Deadlock occurs when there are multiple threads (transactions) in which the lock acquisition order is reversed even in RDBMS like Java deadlock.
--Doesn't wait forever like Java deadlocks (one process continues and the other fails)
--When a deadlock occurs, the JDBC driver throws a java.sql.SQLTransactionRollbackException (* It depends on the JDBC driver implementation. Different versions may throw a different exception)
--The operation at the time of deadlock depends on the RDBMS used and the lock mode setting.
--In order to prevent deadlock, it is necessary to decide the data access order and implement the program.