# Can't run concurrent user-specified transactions (with Begin/Commit)? Why?
**URL:** https://matillioncommunity.discourse.group/t/cant-run-concurrent-user-specified-transactions-with-begin-commit-why/1507
**Category:** Matillion ETL
**Created:** [October 13, 2021, 4:54pm UTC](https://matillioncommunity.discourse.group/t/cant-run-concurrent-user-specified-transactions-with-begin-commit-why/1507 "2021-10-13T16:54:35Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@KevinH](https://matillioncommunity.discourse.group/u/KevinH)
#### Post date: [October 13, 2021, 4:54pm UTC](https://matillioncommunity.discourse.group/t/cant-run-concurrent-user-specified-transactions-with-begin-commit-why/1507/1 "2021-10-13T16:54:35Z")
Hello, we seem to have discovered this limitation where only one user-specified "transaction" can be in progress at a time. Even if they operate on different tables. That is, if a job started with a Begin component, and it is in progress, and it operates on table X ... then any other job (being run in the same environment) that starts with a Begin component must wait until the first one finishes (even if the other job does not operate on table X). **Is that the expected behavior? And if so, why?**
I'm no Redshift DBA, and I've been trying to research this question on the Web, but I can't figure it out. I read things about locks; and how each transaction operates on a snapshot of the database; and "serializable isolation."
I also read [here](https://docs.aws.amazon.com/redshift/latest/dg/c_serial_isolation.html) that "Concurrent transactions are invisible to each other; they cannot detect each other's changes. Each concurrent transaction will create a snapshot of the database at the beginning of the transaction." To me, this seems to imply that Redshift can have multiple transactions executing simultaneously. I'm not sure. But does _Matillion_ prevent us from doing so?
---
### Author:  [@jeberson\_david](https://matillioncommunity.discourse.group/u/jeberson_david)
#### Post date: [November 5, 2021, 6:32pm UTC](https://matillioncommunity.discourse.group/t/cant-run-concurrent-user-specified-transactions-with-begin-commit-why/1507/2 "2021-11-05T18:32:00Z")
if you have some common tables to be updated in both different jobs then this situation will happens . For that check whether there is any common table like audit table update or anything else .
We also faced this type of issues while using begin and commit then we analyzed some points which is to be used while implementing begin and commit
1. Keep the begin and commit as shortly as possible (should not keep from the beginning of the job just keep where the update actions are held or extract actions are held)
2. avoid using multiple begin and commit in same job
3. check for the common tables in concurrent jobs
4. don't apply begin and commit in concurrent jobs which update the same table (if any jobs updating the same table concurrently then the second job should wait until the first job get finished)
5. select \* from svv\_transactions; use this to check deadlock
---
### Author:  [@gjohnson3](https://matillioncommunity.discourse.group/u/gjohnson3)
#### Post date: [March 7, 2023, 9:47pm UTC](https://matillioncommunity.discourse.group/t/cant-run-concurrent-user-specified-transactions-with-begin-commit-why/1507/3 "2023-03-07T21:47:37Z")
I think this response misses the mark David. OP is right... any RDBMS worth its salt will support _multiple concurrent explicit transactions_. It's as simple as _naming_ the transaction when you begin it. Matillion doesn't allow us to take advantage of this. I'm getting the same concurrency errors as Kevin.
Yes, the things you mention are great practices when implementing transactions. That doesn't help me cut down my run times by running logically independent jobs concurrently.