From ba815ce91f392fa8c93d918bf5386eee49e3526c Mon Sep 17 00:00:00 2001
From: Kenichi Ishigaki <ishigaki@cpan.org>
Date: Fri, 17 Apr 2015 01:52:43 +0900
Subject: [PATCH] improved description on immediate transaction (#9)

---
 lib/DBD/SQLite.pm | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lib/DBD/SQLite.pm b/lib/DBD/SQLite.pm
index b9a7ec4..2d017cf 100644
--- a/lib/DBD/SQLite.pm
+++ b/lib/DBD/SQLite.pm
@@ -1373,8 +1373,8 @@ operation, and thus it is possible that another thread or process
 could create a separate transaction and write to the database after
 the C<BEGIN> on the current thread has executed, and eventually
 cause a "deadlock". To avoid this, DBD::SQLite internally issues
-a C<BEGIN IMMEDIATE> when you begin a transaction by
-C<begin_work> or under the C<AutoCommit> mode (since 1.38_01).
+a C<BEGIN IMMEDIATE> if you begin a transaction by
+C<begin_work> or by turning off C<AutoCommit> (since 1.38_01).
 
 If you really need to turn off this feature for some reasons,
 set C<sqlite_use_immediate_transaction> database handle attribute
@@ -1384,6 +1384,9 @@ to false, and the default C<deferred> transaction will be used.
     sqlite_use_immediate_transaction => 0,
   });
 
+Or, issue a C<BEGIN> statement explicitly each time you begin
+a transaction.
+
 See L<http://sqlite.org/lockingv3.html> for locking details.
 
 =head2 C<< $sth->finish >> and Transaction Rollback