2

I have done a small experiment with @FlowScoped beans, whose purpose, as I understand, is to make easier creating "wizard-type" web applications, gradually accumulating data over a sequence of pages, then, once all the data is ready, writing it to the persistent storage (this is just an example, nothing prevents of course to write to the persistent storage during intermediate steps). As I saw, the calls to a @FlowScoped bean are not synchronized, and thus there is in principle the possibility of corrupting the data stored in the bean (by doing a double submit, or launching by any other means two almost simultaneous HTTP requests, which invoke the methods of the bean). This unlike @ConversationScoped beans the calls to which are synchronized.

What puzzles me is that about @SessionScoped beans I have found several links which speak about the need to synchronize the access to a @SessionScoped bean (or recommending not to use them at all, apart from user data which changes rarely), but I have not found anything like that about @FlowScoped beans.

What is considered then to be a "best practice" for using @FlowScoped beans? Am I missing something?

EDIT

@FlowScoped seems, at least to me, to be motivated in part by Spring WebFlow, with which I have some experience, and which, as I know, offers integration with JSF 2 (not all JSF 2.2 features seem to be implemented, but it seems that PrimeFaces is usable, for example). I know that Spring WebFlow + JSF is actually used in "real world" applications, and the issue of thread safety of flow scoped objects is handled there elegantly together with double submit issues (flow execution id must be supplied with each HTTP request, and it expires and a new one is returned after a HTTP request which invokes a Spring WebFlow "action" method: therefore one cannot invoke concurrently more than one "action" method for the same user and flow id).

So I want to understand, what is the best practice in the case of JSF 2.2 if I wish to use the @FlowScoped beans to construct an application "flow" (without using Spring WebFlow). Do I really need to synchronize the access to @FlowScoped beans myself, or there is some standard way to deal with such issues?

John Donn
  • 1,718
  • 2
  • 19
  • 45
  • By default Servlet container uses Thread-per-request strategy. And you never get request dispatched to the same SessionScoped bean instance simultaneously. So do not need to synchronize anything. All this is already done by container. CDI impementation, at least Weld uses Thread local storage. – temaleva Aug 30 '16 at 13:30
  • And this is also true for Flow Scope. You have only assess to the current instance of Flow Scopped Bean. Of course your persistent storage is another history, but it is also Request scoped in default config. – temaleva Aug 30 '16 at 13:41
  • @temaleva you are wrong, for @ SessionScoped beans see http://stackoverflow.com/a/4652829/999264 . As for @ FlowScoped beans my small experiment shows that multiple requests from the same session and flow id are executed concurrently on the same bean instance, so you are wrong again. – John Donn Aug 30 '16 at 20:50
  • Why do you think this guy Max Katz is right without any explanation from him? If you access the same Session Bean from different Tabs, that does not mean you access it concurrently from different Threads, does it? – temaleva Aug 31 '16 at 13:32
  • @temaleva "If you access the same Session Bean from different Tabs, that does not mean you access it concurrently from different Threads, does it?" - by itself no; however if you put, in a non getter method of the bean, System.out.println(">>>entered"), System.out.println("<<>>entered", ">>>entered", "random id for my bean instance 12345", "random id for my bean instance 12345", "<< – John Donn Aug 31 '16 at 13:52
  • Ah, you mean, you need to synchronize your HTTP access, of course you need, but not in terms of synchronized thread calls. You need to have different tabs or windows, you need Window scope. You can use deltaspike to have it. – temaleva Aug 31 '16 at 14:04

0 Answers0