Hello,
when I load a model window, all tasks are executing in the same Default Executor-thread :
2021-01-28 15:04:42,943 [Default Executor-thread-11] INFO CoreService:318 - Init ... 2021-01-28 15:04:42,944 [Default Executor-thread-11] INFO SystemService:318 - Connected to database:
Here Default Executor-thread-11
But, when I click the save button, the Default Executor-thread change : 2021-01-28 15:05:41,922 [Default Executor-thread-10] INFO SystemService:318 - Create or Update id: 5
I lock the record when I read it from the database, and for save I must do the save action in the same thread than my read.
It is possible to make this actions in the same thread ? Regards, Damien
No, you don't have control over which thread is processing a specific servlet request.
The modal window creation and the click on the save button are handled in separate servlet requests. The container (e.g. tomcat) will decide which thread will handle the user request from a common thread pool. If the user takes a long time before clicking save the thread might even be used to process requests from other users.
So from that perspective you shouldn't even consider storing information inside a thread that you didn't create yourself.
I am sure your requirement has more suitable solution than depending on the same thread. I might help with an alternative if you can share the details on what information you need to preserve between requests.
More details:
from a list, I load a record for editing, when I retrieve the record from the database, I lock it.
I use DB2 on IBM i, when I lock the record, I have a job (QZDASOINIT) which lock the record.
When I click on the save button, a new job on the IBM i is use for save action, and it's failed because the record is locked.
It's failed because the save action is not executed by the same thread that init action.
I think that I must save the DB session and reuse-it in the save action.
OK if it's a hard requirement then you have to create your own thread (don't rely on servlet threads) holding the lock and performing the update. Still I'd first check whether there's an alternative. If not make sure there's a reasonable timeout, in case the client never get's back to unlock.
cor3000 ( 2021-02-12 12:46:56 +0800 )editAsked: 2021-01-28 22:27:34 +0800
Seen: 14 times
Last updated: Feb 10 '21
Tags
People
Badges
Help
