diff --git a/badger.go b/badger.go
index 1b5e35f24..eb13c5d88 100644
--- a/badger.go
+++ b/badger.go
@@ -711,7 +711,7 @@ func (tx *BadgerTx) PutContainer(index, field, view string, shard uint64, ckey u
 	entry := badger.NewEntry(bkey, by).WithMeta(ct)
 	tx.mu.Lock()
 	err := tx.tx.SetEntry(entry)
-	tx.mu.Unlock()
+	defer tx.mu.Unlock()
 
 	// ErrTxnTooBig is returned if too many writes are fit into a single transaction.
 	// badger docs: "An ErrTxnTooBig will be reported in case the number of pending
@@ -719,14 +719,11 @@ func (tx *BadgerTx) PutContainer(index, field, view string, shard uint64, ckey u
 	// is best to commit the transaction and start a new transaction immediately."
 	//
 	if err == badger.ErrTxnTooBig {
-		// As now, we don't deal with this. The current strategy is to recommend setting lots
-		// of bits on your container and then change it in a single operation
-		// within the txn, rather than having too many SetEntry() calls in a transactions.
-		// The tests currently have these default limits:
-		// maxBatchCount:104857, maxBatchSize:10066329
-		// For now, we just panic. The user should re-write their code to do
-		// most of the work of setting bits outside the transaction.
-		panic(fmt.Sprintf("error: do not do more than 100K writes in a transaction: '%v'", err))
+		// The integration tests do large bit level loads that exceed 10MB.
+		// So we autocommit and start a new Txn.
+		panicOn(tx.tx.Commit())
+		tx.tx = tx.Db.db.NewTransaction(tx.write)
+		return tx.tx.SetEntry(entry)
 	}
 	return err
 }
diff --git a/index.go b/index.go
index 4a483472f..766c8c791 100644
--- a/index.go
+++ b/index.go
@@ -38,7 +38,7 @@ func init() {
 	go func() {
 		// give time for env var TXSRC to be set.
 		//time.Sleep(5 * time.Second)
-		//CPUProfileForDur(5*time.Minute, "cpu.pprof")
+		//CPUProfileForDur(time.Minute, "cpu.pprof")
 		//CPUProfileForDur(15*time.Second, "cpu.pprof")
 	}()
 }