What's a better performance-wise: unconnected @Transactional methods or one @Transactional method with propagation, adjusting transaction timeout?

[TarekSaid]

Using: quarkus 3.2.12.Final, hibernate-panache, non-reactive programming

I have a microservice with jobs that are scheduled for execution by an external scheduling service. The job needs to process multiple entities. To avoid parallel executions (in case the job hasn't finished before it's called again), we have set up a job_lock table with the job name, and a JobLockRepository#isJobUnLocked, with pessimist write lock and skip_locked (-2) lock timeout, that returns false if the job record cannot be found (i.e. its jobName doesn't exist, or the job is already being processed):

return find("jobName", jobName)
                .withLock(LockModeType.PESSIMISTIC_WRITE)
                .withHint(HINT_SPEC_LOCK_TIMEOUT, SKIP_LOCKED)
                .singleResultOptional()
                .isPresent();

Therefore, the Job executor (that checks if the job is locked and executes the specified job) is marked as @Transactional, which is of course propagated to the job execution itself. The problem is that the job execution involves calling different external services (using vertx) for each entity before a batch update, and, if a service is unstable and takes too long to respond, it causes a transaction timeout and then an error performing the rollback, since the thread is blocked, waiting for the external service's response. And, unfortunately, executing the entity processing in parallel cannot be done, because of a proprietary shared ContextManager (that comes from a lib, so I can't change that) that needs to be set per entity being processed.

To solve this, I have thought of two possible solutions:

1. reduce the amount of entities processed per job execution and increase the transaction timeout. That would involve less changes, maintain the @Transactional propagation. But, by reducing the amount of entities processed at once, it could negatively affect the entire solution (of which this microservice is only a small part of). Plus, it would be a big timeout time, if I calculate the external services timeouts * entities processed (at least 10 minutes), which seems a bit unreasonable;
2. refactor the code, add a JobLocked#locked boolean field, manage locking and unlocking manually using this field, remove the @Transactional annotation from the job executor and only annotate the methods that persist the data with @Transactional, so most of the job execution (including calling the external services) wouldn't involve a transaction. The drawback is that the entities are now detached between fetching them from the DB and persisting them, and I wouldn't be able to use PanacheRepository#persist(List<Entity>). Instead, I'd need to use Panache.getEntityManager().merge(Entity) for each entity. Finally, I can't use lazy fetching anymore, everything has to be EAGER, since with the detached entities, there's no Hibernate Session to fetch them only when the getter is called.

My question is: which solution would perform better, in my case? Would smaller @Transactional methods impact the performance, since (as I understand it) it'd be opening and closing multiple smaller db transactions, and fetching all relationships eagerly? And will Panache.getEntityManager().merge(Entity) perform a batch operation if I only flush after all entities are merged? Or should I use solution 1, and keep using PanacheRepository#persist(List<Entity>)? Or would there be a third, better solution? Granted, having reactive, non-blocking operations would certainly help, but it would be a huge refactor...

[TarekSaid]

nevermind, I'll try a different approach. When the scheduled job runs, I'll query the entities to process and send them to a kafka topic, then the consumer with process each entity separately.