Recognition of threads able to update UI components


i’ve searched on the web for some hints but found nothing. Maybe i was searching wrong.

My question is:

How can I determine if the current Thread im executing is eligible to modify UI components?

this is what i do now for UI update:

UI.getCurrent().access(new Runnable() {
            public void run() {
               //modify some ui

In some cases i dont have to do this, it works right away in the current Thread, but sometimes not and i get an error.
When i compared the Threads in the Runnable and Outside the Runnable - it was the exact same thing = http-bio-8080-exec-10

What can i do to know from the code that this is the right place to invoke UI.getCurrent().access() or do it right away?

I tried to search for differences in threads look for:

i didnt see any rule or pattern.

Thanks for Your time,


This issue seems very interesting. i have tried to make it on my own, but I also have problem to define when i can modife UI. Sometimes it works very well sometimes not.

I would be grateful if someone could explain how it should be done properly.


If in any doubt, use UI.access - it’s never wrong.

Basically, the only place where you don’t need it (or some other means to lock the session) is when you know you’re in a thread that’s currently handling a client request (for instance, in a component event listener). In cases you don’t know whether this is the case, for instance in a method that could be called either from an event listener or a background worker thread, you should either do UI.access just to be sure, or alternatively simply access the UI directly and document in the method’s contract that its caller must take care of locking.

If you think you have a use case where you must programmatically check whether the session is locked, please describe it here and we’ll see what would be the best way to do it.

Thanks for the response :slight_smile:

How can i determine when im in a "
thread that’s currently handling a client request
" ?

Button button = new Button("Click this");
button.addClickListener(new ClickListener() {
    public void click(ClickEvent event) {
        // No UI.access needed here, this is how Vaadin has always worked.
        // The same goes for all other component event listeners.

If your app never spawns a background thread, or schedules any work to be done asynchronously in a thread pool or similar, you never need UI.access(). For all UI access that’s done from a thread that’s either spawned by you, or that is running a task you’ve scheduled using some means like an Executor, you must use UI.access() or some other way to lock the session. Ideally your application’s architecture should make it easy to distinguish these two cases. As I said, if you have methods that might be invoked both from event handling and from a background thread, the safe bet is to use UI.access.

I have a modular architecture, i write modules for my main app. Some of them provide API - there i dont know in which thread i will be invoked.

I was hoping there is a way to write an if statment which would decide if this is a
“thread that’s currently handling a client request” or not?

Right. So, you would have

if(handlingRequest()) {
} else {
  ui.access(new Runnable() {
    public void run() { doStuff(); }

But why would you want this? Just do

ui.access(new Runnable() {
  public void run() { doStuff(); }

It’s always correct and incurs practically no overhead if the session is already locked. Or do you have a use case where you want to do different things depending on whether there’s a request active (or perhaps, depending if the session is locked, no matter by whom)?

It will work with ui.access() all the time, I was worrying about perfomence issues a bit.

Thank You very much :slight_smile: