I like using DOs for transactions more
I like using DOs for transactions more simply because you control the thread of processing. Run a bunch of SQL in synchronous code with the right error handling in place and you have transactions.
Another approach I use when coordinating changes async across D1/DO other resources in a saga pattern.
3 Replies
Unfortunately, the D1 object doesn't support transactions.
DO does support them in SQL form, but since I'm using D1, I'll be using DO in an async manner as well. What I'm wondering is: whether I use it normally or in the same format within DO, it'll run asynchronously either way.
Right now, there's not much usage, but I want to avoid running into issues in the future.
Instead of using a general D1 object, I considered creating a separate DO for each user and managing it with SQL in a synchronous way. But I'm not sure how feasible that is in terms of cost and architecture.
You can create a batch handler on the DO to handle subsequent SQL in a single async request from the caller, but on the DO, the full request / RPC call is synchrounous and atomic.
You can also send to D1 via the batch call instead to do consecutive sql as a transaction. The benefit of the DO approach is you can invoke custom logic in the batch handler you create. In my case, I have a pattern for ordering SQL and pulling data from SQL statements to re-use in later statements in the same RPC call. Giving me the ability to do something like create a user account, pull an new account ID, and re-use that ID in FK transactions in the same RPC.
I got it, thanks.