Previously, DatabasePopulatorUtils#execute looked up a Connection from
the given DataSource directly which resulted in the executed statements
not being executed against a transactional connection (if any) which in
turn resulted in the statements executed by the populator potentially
not being rolled back.
Now DataSourceUtils#getConnection is used to transparently take part in
any active transaction and #releaseConnection is used to ensure the
connection is closed if appropriate.
Issue: SPR-9457
SPR-7680 added QueryTimeoutException to Spring's DataAccessException
hierarchy, but did not integrate it into the
SQLExceptionSubclassTranslator; it was added mainly to accomodate users
defining their own custom exception translators.
However, it does make sense to translate any SQLTimeoutException to this
new QueryTimeoutException type, and this commit makes that change. It
does represent a slight backward-incompatibility, given that
QueryTimeoutException extends TransientDataAccessException, whereas
SQLExceptionSubclassTranslator previously returned the more specific
TransientDataAccessResourceException for any SQLTimeoutException.
It is expected that this incompatibily will be very low-impact, i.e. not
affecting many (if any) users. In any case, a major release (Spring 3.2)
is the right time to introduce such a change, and the migration path is
straightforward: any users depending on catching
TransientDataAccessResourceException in the case of query timeouts
should update those catch blocks to expect QueryTimeoutException
instead. Care should also be taken to ensure correctness of existing
catch blocks expecting TransientDataAccessException, as these blocks
will now catch QueryTimeoutException as well.
Issue: SPR-9376, SPR-7680
* 3.1.x: (61 commits)
Compensate for changes in JDK 7 Introspector
Avoid 'type mismatch' errors in ExtendedBeanInfo
Polish ExtendedBeanInfo and tests
Infer AnnotationAttributes method return types
Minor fix in MVC reference doc chapter
Hibernate 4.1 etc
TypeDescriptor equals implementation accepts annotations in any order
"setBasenames" uses varargs now (for programmatic setup; SPR-9106)
@ActiveProfiles mechanism works with @ImportResource as well (SPR-8992
polishing
clarified Resource's "getFilename" method to consistently return null
substituteNamedParameters detects and unwraps SqlParameterValue object
Replace spaces with tabs
Consider security in ClassUtils#getMostSpecificMethod
Adding null check for username being null.
Improvements for registering custom SQL exception translators in app c
SPR-7680 Adding QueryTimeoutException to the DataAccessException hiera
Minor polish in WebMvcConfigurationSupport
Detect overridden boolean getters in ExtendedBeanInfo
Polish ExtendedBeanInfoTests
...
This renaming more intuitively expresses the relationship between
subprojects and the JAR artifacts they produce.
Tracking history across these renames is possible, but it requires
use of the --follow flag to `git log`, for example
$ git log spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history up until the renaming event, where
$ git log --follow spring-aop/src/main/java/org/springframework/aop/Advisor.java
will show history for all changes to the file, before and after the
renaming.
See http://chrisbeams.com/git-diff-across-renamed-directories
