0

In my Vaadin app, I have some class methods that can both be called from an event triggered in the server or due to a user action.

I need a way to find out whether current code is executing in a UI thread (a thread that is currently handling a request from the UI) or not.

Is there a way for this. Can I assume that if UI.getCurrent() returns non null reference, this is a UI thread?

Lahiru Chandima
  • 22,324
  • 22
  • 103
  • 179

2 Answers2

0

Yes.

From documentation:

Gets the currently used UI. The current UI is automatically defined when processing requests to the server. In other cases, (e.g. from background threads), the current UI is not automatically defined.

The other way of checking it would be by obtaining current stacktrace and looking into it (for com.vaadin calls). Tons of examples are here: How can I convert a stack trace to a string?

Community
  • 1
  • 1
kukis
  • 4,489
  • 6
  • 27
  • 50
  • I played around with threads a little and found that it is not the case. If I start a new thread from a UI thread, new thread also returns a valid `VaadinSession` if I called `VaadinSession.getCurrent()`. Thread locals get inherited to newly created thread. – Lahiru Chandima Aug 08 '15 at 13:49
  • Still, the method with obtaining stacktrace will work. – kukis Aug 08 '15 at 14:19
  • I can't understand what you mean by `obtaining stacktrace` but I don't think it is appropriate to access UI elements just because `VaadinSession.getCurrent()` returned a non null reference. Because current thread can be just another thread which got `VaadinSession` thread local from its parent UI thread. If I do so, since `VaadinSession` is not locked by current thread, it may cause problems. – Lahiru Chandima Aug 08 '15 at 14:35
  • For that, use [`ui.accesss`](https://vaadin.com/api/com/vaadin/ui/UI.html#access%28java.lang.Runnable%29) – Mark Rotteveel Aug 08 '15 at 15:03
0

According to this post by Johannes Dahlströms, no - you cannot rely on a null value:

Well, yes and no.

The reference returned by UI.getCurrent() is stored in an inheritable ThreadLocal. When a UI is accessed, either via a client request, or by the user invoking UI.access(), the UI.getCurrent() value is set to that UI.

In an arbitrary background thread, outside a UI.access() invocation, there cannot be a concept of a "current UI". Why, then, UI.getCurrent() in many cases does return a non-null value even in a background thread? This is because, as mentioned, the ThreadLocal is inheritable. That is to say, if a child thread is spawned by a thread that at that time has UI.getCurrent() set, the value is inherited by the child thread. This is most likely the effect you're seeing. It makes some things a bit more convenient, but I'm not actually sure it's actually a good idea for it to be inheritable - it stretches the meaning of "current" and may cause the user to forget to do proper synchronization before accessing the "current" UI.

Tunaki
  • 132,869
  • 46
  • 340
  • 423
Aydin K.
  • 3,309
  • 36
  • 44