Fix session perf. in synchronize/http req. context#66
Fix session perf. in synchronize/http req. context#66lalmeras wants to merge 1 commit intoopenwide-java:masterfrom
Conversation
We must not use http request session during artifact synchronization.
| } | ||
| }); | ||
| thread.start(); | ||
| thread.join(); |
There was a problem hiding this comment.
Why do you start it in a new Thread if you need to wait for it here ? Why not just execute it in the current thread ?
There was a problem hiding this comment.
Synchronization process need to run in a separate Hibernate session for performance reason. Running it into a separate Thread and joining the thread is a way to run it with an isolated session without interrupting the HTTP thread&request-scoped session.
Another way to proceed would be to deal with Thread-scoped/TransactionSynchronizationManager registered session (save, replace, artifact synchronization, restore): it does not seem to me there is an helper for this ?
There was a problem hiding this comment.
You know better the details how this leads to better performance in your app, but this is how I see it from outside:
Wicket is thread-per-request based so if you use OpenSessionInViewFilter then you have one request scoped DB transaction. If you need to start a new one for the Maven sync then you can use @Propagation.RequiresNew for this service method. If you don't make it in a separate transaction then the only drawback I see is that the request-scoped transaction may get rolled back if something fails later.
There was a problem hiding this comment.
We are transaction-less at the time I do this trick (only session is opened at request scope, transaction are kept at service scope). This pattern is a bit original and can be tricky when rollbacks are involved, but work flawlessly for a lot of our projects.
I do not use @transactional mechanism as I do not want to wrap whole synchronization in a transaction (we deal with transaction around each artifact synchronization). I do not dig into @transactional configuration to see if it is possible to let it open a session without starting a new transaction.
As transactions are also separated (Thread trick also isolates transactions), there is no request-scoped transaction, and page / synchronization data do not need to be synced, I do not think there is any problem with transaction isolation / rollback.
2 participants
We must not use http request session during artifact synchronization.
Not tested for the moment (I have to prepare a test database). The purpose of this PR is to show a pattern to enhance performance when artifact synchronization is launched from admin console.