(Major) downsides/caveats of using explicit transactions vs implicit transactions

General Newbie Questions
1

Helllooooo :wave:

I've been told this is THE place to get some answers to your questions and really appreciate whoever's looking into this!

Coming from a postgres/sql database world I'm a big fan of using explicit transactions in whatever ORM I'm using. So having the ability to commit/rollback on my own accord. The main use case for this is when making 3rd party api calls to sync some data with an external service or when I want to create multiple nodes in one go and I need all of them to succeed for it to make any sense.

So I found the beginTransaction method on a session and this allows me to do exactly this:

const session = createSession()
const tx      = session.beginTransaction();

try {
	  await tx.run(queries.createUser, { name: "Sam"  });
	  await tx.run(queries.createTeam, { name: "Sam's team"  });
	  await call3rdPartyApi(user)
	
	  await tx.commit();
} catch (error) {
	  await tx.rollback();
} finally {
	 await session.close()
}

But my biggest question is whether or not this is any worse performance wise versus using singularsession.readTransaction and session.writeTransaction for every single query as that's what I'm doing currently. And when I say performance wise I mainly mean the number of connections to the database and afraid of reaching the limit(s). But would be good to know if there's anything else

I'm also concerned about deadlocks. Is the lock on the node I'm trying to update/read released as soon as the await tx.run line finishes or only after I commit the entire transaction? If the 3rd party api call takes a really long time to finish I'm assuming the lock will exist until the transaction is committed?

Thank you sooooo soooo much for looking into this,
truly much appreciated!!