# Writing to db in Asynchronous Loop

**URL:** <https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079>\
**Category:** Ignition\
**Created:** [August 19, 2013, 3:33pm UTC](https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079 "2013-08-19T15:33:10Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![mikehill100](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@mikehill100](https://forum.inductiveautomation.com/u/mikehill100)\
**Post date:** [August 19, 2013, 3:33pm UTC](https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079/1 "2013-08-19T15:33:10Z")

</div>

I have an application that continually reads from a serial port using an asynchronous loop. When the program receives the data it will need to write it to a database.

Sometimes, however the database write takes a very long time. Would it be frowned upon for me to begin another asynchronous function that writes to the database and call it from my asynchronous loop? Is there an alternative?

Thanks!

Mike

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 19, 2013, 3:56pm UTC](https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079/2 "2013-08-19T15:56:33Z")

</div>

The thing you’re going to have to worry about is the async write-to-db calls ‘stacking’ up. If you’re reading data from the serial port faster/more often than you can write it to the db your application will eventually fall apart.

---

<div class="post-metadata">

**Author:** ![mikehill100](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@mikehill100](https://forum.inductiveautomation.com/u/mikehill100)\
**Post date:** [August 19, 2013, 6:09pm UTC](https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079/3 "2013-08-19T18:09:20Z")

</div>

Do you know how many writes can stack on top of each other?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 19, 2013, 6:13pm UTC](https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079/4 "2013-08-19T18:13:21Z")

</div>

Every async call runs in a new thread. The order in which the run is essentially non-deterministic and the number really just depends on when you run out of memory.

If you’re writing to a DB in this async function and the writes can’t complete as fast as you’re reading first you’ll run up against the DB connection limit, then additional threads would block waiting to get a DB connection, and that’s where the ‘stacking’ would begin.

---

<div class="post-metadata">

**Author:** ![mikehill100](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@mikehill100](https://forum.inductiveautomation.com/u/mikehill100)\
**Post date:** [August 19, 2013, 6:15pm UTC](https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079/5 "2013-08-19T18:15:29Z")

</div>

Thanks! That was exactly the answer I was looking for.

Also, what is the timeout on system.db.runPrepQuery? What happens if it does time out?

---

<div class="post-metadata">

**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\
**Post date:** [August 19, 2013, 6:33pm UTC](https://forum.inductiveautomation.com/t/writing-to-db-in-asynchronous-loop/7079/6 "2013-08-19T18:33:39Z")

</div>

If you’re running these queries from the client there’s a 60s timeout between client and gateway for anything.

Additionally, there’s a timeout on getting a connection from the pool, which defaults to 5s and is settable. The actual querying does not have timeout…

system.db.runPrepQuery should throw an exception if any of these occur.
