Ask questions and see you at June, 7th, 8.PM. CEST: https://youtu.be/Uz1nLi5APVw
Also checkout recent episode:
Please keep the questions Jakarta EE-stic. Means: as short and as concise as only possible. Feel free to ask several, shorter questions. Upcoming airhacks.tv events are also going to be announced at meetup.com/airhacks
(back to the BCE on the back-end)
Should the REST resource class in the boundary be
@Transactional
?In some of your workshops/demos you make the REST resource a @stateless (in addition to the manager class which is and always should be
@Stateless
). Is that just a hack for the purpose of having the methods counted (and perhaps pooling) or do you actually intentionally want the transaction to start there (naturally@Stateless
implies transactions)?My understanding was that each discrete use case should be clearly starting in the protocol agnostic "manager" portion of the boundary whereas the REST resource class is just an "adapter" layer. Including REST methods in the transactions would be a "code smell" indicating that we are trying to do something outside of the "unit of work" scope that maybe should be part of it (i.e. executed atomically).