For arguments sake, let's say a system has a collection of jobs, which will be edited by recruiters. There are several key use cases - view job, edit job, delete job, update job status for example, and each will start with searching the jobs.
A single recruiter is most likely to be editing a specific job they are responsible for, but it's necessary to cater for edits made by other recruiters from same recruitment company for example.
I'm thinking I would @Begin a conversation when first searching, and would @End on completion of a singular edit job or delete job use case. Optimistic locking will enable system to catch when recruiterB attempts to updated a job that recruiterA just updated/deleted, leading recruiterB to re-start conversation/merge data. Also, I could pick a sensible timeout value for the search result screen, to ensure that the data is reasonably fresh before performing rest of use case.
Does this seem the best way to go, or can anyone think of better?
This type of use case grouping will be very common in all kinds of domains (eg updating of product information), and it would be great to get a feel for how others might do it differently. Most of the Seam examples are session scoped with regards to result based use cases, but the DVD example approach seemed a better fit considering concurrency issues.
As an alternative, I could begin the conversation at the point where a recruiter starts to edit the job, and search conversation is limited to event scope. Job search results would be updated each time the recruiter views the browse page, and I could set the "job to edit" for the edit action by using JSF rather than the @DataModelSelection approach.
