We have a Websphere JEE application that requires parallelization, for which we're looking to use CommonJ work components.
Each 'thread' would require its own view onto data coming from a database. Most of this would be pre-fetched, but it would still need to go to the database to get some. We anticipate that the duration of the overall work of all of these threads would be 'long' (i.e. enough time for underlying data to be changed).
As a result we need to ensure isolation of the data in use by the application and queried during the course of the threads' work.
It seems that the only way to ensure this is to have a 'global' transaction and use XA transactions. But we'd like to avoid this complexity (and overhead) if at all possible, and are looking for ideas or alternatives: any thoughts?
Also, to what degree (if at all) do Common-J Work Components support container managed transactions?
@Karl: Perhaps I just meant overhead. Our thought was that XA transactions and Messaging incur overhead that Common-J work components sharing a transaction could avoid? The dataset being operated on would be >300k distinct rows of data, each needing ~100 calculations done on it. Whereas these could be divided up onto different threads operating on shared, cached, read-only data, the comparative memory overhead of copying onto/reading off a queue seems prohibitive. Would you agree?
@Karl: Tens to low-hundreds of milliseconds per entity. We're also focusing on improving the logic processing as a separate task.
Do I need to use XA transactions when what is required that all threads have a consistent view of data in a single database? My answer to this is that each thread would require its own JPA EntityManager (e.g. connection) and would need XA in order to coordinate their access.
But, if I can do this without XA then so much the better, no?