Fire events when starting and ending session access.

[vaadin-bot]

Originally by @Legioth

---

Frameworks like JPA are often used with a transaction-per-request pattern where a new transaction is started at the beginning of every request and then committed or rolled back the request after the request has been handled.

In Vaadin 6, this was usually implemented using TransactionListener or HttpServletRequestListener. Vaadin 7 removed support for those features and it was instead recommend to use a servlet filter (see e.g. #10983). The introduction of server push and UI.access(Runnable) in Vaadin 7.1 furthermore means that the same HTTP request might (asynchronously) touch multiple sessions that should probably each have their own transaction. The push support also encourages patterns where a session is accessed outside the context of a HTTP request, e.g. from a custom worker thread.

All in all, it seems that the concept of transaction-per-request can no longer work sensibly with Vaadin applications. Transactions should instead be bound to session access; starting a transaction when locking the UI and ending the transaction when unlocking.

To support this, events should be fired whenever VaadinSession is locked or unlocked. Some thoughts about the implementation:

• Unlocking events should be fired in the opposite order of locking events.
• The event could include information on why the access was initiated, e.g. request initiated by the client, heartbeat handling or access() from an unrelated request or a custom thread.
• Events should only be triggered when using one of the access methods - manually retrieving the lock instance and directly operating on it should not fire any events.
• access() for the same session during a lock event would queue the Runnable to be run after all listeners have been notified.
• access() for the same session during an unlock event would schedule a new access (firing new lock and unlock events) after all listeners have been notified. The lock is released between the two accesses to give other accessors a chance.
• Data that might be useful in the unlocking event:
  • Which UIs have been marked as dirty during the access
  • For which UIs a response or push message has been produced
  • Did the access end normally or was there an uncaught exception?

---

Imported from https://dev.vaadin.com/ issue #12256

[vaadin-bot]

Originally by @jdahlstrom

---

Would these be "lock-acquire listeners" or "access listeners"? These are logically distinct, as queued access invocations are run in the same critical section. If the former, would the listeners be run when reentrantly acquiring the lock, or only at the actual boundaries of the critical section?

[vaadin-bot]

Originally by @Legioth

---

At least the JPA would just get more complicated if events would be fired for reentrant access. I don't know any other use case that would benefit from doing so either.

Queued access invocations are contributing to the same response or push message, so it would probably make sense to just draw the boundary at the critical section, i.e. "lock-acquire listeners". For the naming I would still like to stay away from using the word "lock" because it makes this sound too complicated. My suggestions would be:

• AccessListener even though multiple accesses using the same critical section would be covered by only one set of events. The logic is basically that 1) now the contents of this session will be accessed and 2) now the access is completed and the session will not be used again until there's a new event.
• TransactionListener even though the semantics are not the same as the similarly named listeners in Vaadin 6. One problematic detail with this name is that Vaadin does not in itself support transactions since there's no way of rolling back changes to the UI state.

[stale[bot]]

Hello there!

It looks like this issue hasn't progressed lately. There are so many issues that we just can't deal them all within a reasonable timeframe.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!