edit SQLite documentation and transaction example (#621)

Minor finishing touches to give the documentation a sense of completion.
Fix one major error in transaction example: Rollback was deferred
instead of Commit.

Author: dkotik

_examples/pubsubs/sqlite/transaction.go

@@ -10,16 +10,18 @@ import (
 )
 
 func publishWithInTransaction(db *sql.DB) {
-	tx, err := db.BeginTx(context.Background(), &sql.TxOptions{Isolation: sql.LevelReadCommitted})
+	tx, err := db.BeginTx(context.Background(), &sql.TxOptions{
+		Isolation: sql.LevelReadCommitted,
+	})
 	if err != nil {
 		panic(err)
 	}
 	defer func() {
-		_ = tx.Rollback()
+		_ = tx.Commit()
 	}()
 
 	publisher, err := wmsqlitemodernc.NewPublisher(
-		tx,
+		tx, // transaction presented as database
 		wmsqlitemodernc.PublisherOptions{
 			// schema must be initialized elsewhere before using
 			// the publisher within the transaction

docs/content/pubsubs/sqlite.md

@@ -14,12 +14,11 @@ SQLite Pub/Subs provide the easiest way to publish and process events durably, s
 
 You can find a fully functional example with SQLite in the [Watermill examples](https://github.com/ThreeDotsLabs/watermill/tree/master/_examples/pubsubs/sqlite).
 
-## Vanilla ModernC Driver vs Advanced ZombieZen Driver
+## ModernC vs ZombieZen Driver
 
-The **ModernC driver** is compatible with the Golang standard library SQL package and works without CGO. It has fewer dependencies than the ZombieZen variant and uses the `modernc.org/sqlite` pure Go SQLite implementation.
+The vanilla **ModernC driver** is compatible with the Golang standard library SQL package and works without CGO. It has fewer dependencies than the ZombieZen variant and uses the `modernc.org/sqlite` pure Go SQLite implementation. Most users should pick this driver for full compatibility with the standard library.
 
-The **ZombieZen driver** abandons the standard Golang library SQL conventions in favor of [the more orthogonal API and higher performance potential](https://crawshaw.io/blog/go-and-sqlite). Under the hood, it also uses the ModernC SQLite3 implementation and does not need CGO. Advanced SQLite users might prefer this driver for its performance benefits.
-It is about **6 times faster** than the ModernC variant. It is currently more stable due to lower level control. It is faster than even the CGO SQLite variants on standard library interfaces, and with some tuning should become the absolute speed champion of persistent message brokers over time.
+The advanced **ZombieZen driver** abandons the standard Golang library SQL conventions in favor of [the more orthogonal API and higher performance potential](https://crawshaw.io/blog/go-and-sqlite). Under the hood, it also uses the ModernC SQLite3 implementation and does not need CGO. Advanced SQLite users might prefer this driver for its performance benefits. It is about **6 times faster** than the ModernC variant. It is currently more stable due to lower level control. It is faster than even the CGO SQLite variants on standard library interfaces, and with some tuning should become the absolute speed champion of persistent message brokers over time.
 
 ### Characteristics
 
@@ -30,6 +29,8 @@ It is about **6 times faster** than the ModernC variant. It is currently more st
 | GuaranteedOrder     | yes        |                                                   |
 | Persistent          | yes        |                                                   |
 
+Like the [BoltDB](../bolt/) implementation, the SQLite drivers are imbeddable into your application. They do not require any additional infrastructure other than a mounted persistent disk. Their advantage over the BoltDB Pub/Sub is supporting consumer groups and guaranteed order.
+
 ## Vanilla ModernC Driver
 
 ### Installation
@@ -127,11 +128,6 @@ The default marshaler handles:
 
 Both drivers automatically handle message marshaling and unmarshaling, so no custom marshaler configuration is typically required.
 
-## Similar Projects
-
-- <https://github.com/davidroman0O/watermill-comfymill>
-- <https://github.com/walterwanderley/watermill-sqlite>
-
 ## Caveats
 
 SQLite3 does not support querying `FOR UPDATE`, which is used for row locking when subscribers in the same consumer group read an event batch in official Watermill SQL PubSub implementations. Current architectural decision is to lock a consumer group offset using `unixepoch()+lockTimeout` time stamp. While one consumed message is processing per group, the offset lock time is extended by `lockTimeout` periodically by `time.Ticker`. If the subscriber is unable to finish the consumer group batch, other subscribers will take over the lock as soon as the grace period runs out. A time lock fulfills the role of a traditional database network timeout that terminates transactions when its client disconnects.