<p dir="auto"><strong><a href="https://jira.spring.io/secure/ViewProfile.jspa?name=ilang98" rel="nofollow">Ilanchezhian</a></strong> opened <strong><a href="https://jira.spring.io/browse/SPR-2617?redirect=false" rel="nofollow">SPR-2617</a></strong> and commented</p>
<p dir="auto">During update by using JdbcTemplate.update(String sql, Object[] args), I encounter exception due to deadlock. This is thrown as an SQLException. Exception log is</p>
<p dir="auto">exception: PreparedStatementCallback; uncategorized SQLException for SQL [UPDATE EMP_INFO SET ORG_NAME=?, EMP_MAME=?, WHERE EMP_ID=?]; SQL state [40001]; error code [1205]; Transaction (Process ID 58) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.; nested exception is java.sql.SQLException: Transaction (Process ID 58) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.</p>
<p dir="auto">In the above scenario, I encounter couple of issues:</p>
<ul dir="auto">
<li>From application program code there is no way I can capture this exception (SQLException), and provide the information message. To do this I am forced to capture root exception (Exception) and provide necessary information message.</li>
<li>Currently JdbcTemplate.update() method throws only 'DataAccessException' but when we look at source code we can see it internally executes PreparedStatementCallback.doInPreparedStatement() method, this method  throws SQLException. But as root JdbcTemplate.update() throws only 'DataAccessException' so in this case I am not able to catch any SQLException. Please let me know is this a practice that I should not catch any SQLException in my application code?</li>
</ul>
<hr>
<p dir="auto"><strong>Affects:</strong> 2.0.6</p>
<p dir="auto"><strong>Issue Links:</strong></p>
<ul dir="auto">
<li><a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="398063355" data-permission-text="Title is private" data-url="https://github.com/spring-projects/spring-framework/issues/6388" data-hovercard-type="issue" data-hovercard-url="/spring-projects/spring-framework/issues/6388/hovercard" href="https://github.com/spring-projects/spring-framework/issues/6388">#6388</a> SQL Server Error Code 1205 = DeadlockLoser (<em><strong>"duplicates"</strong></em>)</li>
</ul>
<p dir="auto"><strong><a href="https://jira.spring.io/secure/ViewProfile.jspa?name=sethladd" rel="nofollow">Seth Ladd</a></strong> opened <strong><a href="https://jira.spring.io/browse/SPR-1190?redirect=false" rel="nofollow">SPR-1190</a></strong> and commented</p>
<p dir="auto">Browsing the ThemeResolver implementations, I noticed an oddity.  The CookieThemeResolver does not extend from AbstractThemeResolver.  This creates an odd schism in the hierarchy.</p>
<p dir="auto">In my opinion, the CookieThemeResolver IS-A AbstractThemeResolver much more than a CookieGenerator.  It can certainly use the CookieGenerator via HAS-A and delegatation.  It would appear that no one uses the CookieThemeResolver directly as a CookieGenerator, so the change shouldn't break any client code.</p>
<p dir="auto">It also creates some duplicate code and logic, as both AbstractThemeResolver and CookieThemeResolver implement a ORIGINAL_DEFAULT_THEME_NAME and setters.  They are the same in both classes, and their intentions are the same.  For this reason alone I believe CookieThemeResolver should extend AbstractThemeResolver directly.</p>
<p dir="auto">Let me know if you'd like a patch.</p>
<p dir="auto">Thanks!<br>
Seth</p>
<hr>
<p dir="auto"><strong>Affects:</strong> 1.2.3</p>