For what it's worth, what we've been doing is building a separate service for talking to the database, which itself maintains a single common database connection pool.
I can't say yet whether that turns out to be a good idea or a poor one. (I'm not the one who designed and built it.) One notable feature of our implementation is that it eliminates all possibility of using transactions -- a design oversight that worries me.
You could build the transaction support into the database service. Then when you need to write multiple things, you put them into a queue as a single work unit, and let your abstraction deal with taking the work unit off the queue and putting into the database in a single transaction.
This has the added effect of making your system more reliable because you'll be using queues and you have a shorter window when a process can die and hang a db connection that is trying to roll back.
You certainly COULD (and if I were designing it I would have either done that or allowed callers to request a transaction in which case a connection is temporarily reserved for that client and a token returned which can be used to continue the transaction). But the people designing it DIDN'T do either. Which is part of why I question their design.
I can't say yet whether that turns out to be a good idea or a poor one. (I'm not the one who designed and built it.) One notable feature of our implementation is that it eliminates all possibility of using transactions -- a design oversight that worries me.