Hello everyone!
I've following problem. The project I'm working in has two main
functionalities: first is gathering data, and the second is data
processing.
First one is implemented as EJB. There are mainly only simple CRUD
operations.
The data processing is triggered by the user. Because of time
consuming, I'm planning to apply JMS messages in order to communicate
between the EJB and processing mechanism. The problem is I don't know
how to implement process executor. Because of great amount of data and
need of using complex aggregate functions, I don't want use EJB. I
considered standard JDBC API, but I don't know how it impacts on EJB
transactions. I also haven't got any ideas what should consume JMS
messages. Since process execution could take several hours, I don't
want put it into MDB, rather MDB should trigger separate thread. Do
you know any patterns, which can by used in my situation?
Thanks for your advice,
MP
Robert Klemme - 23 Jan 2004 13:53 GMT
> Hello everyone!
> I've following problem. The project I'm working in has two main
[quoted text clipped - 9 lines]
> considered standard JDBC API, but I don't know how it impacts on EJB
> transactions.
If you manipulate the data store from two sides (EJB and directly via
JDBC) you're likely to run into trouble. This can result in all sorts of
consistency and transaction problems.
> I also haven't got any ideas what should consume JMS
> messages. Since process execution could take several hours, I don't
[quoted text clipped - 3 lines]
> Thanks for your advice,
> MP
It's a bit difficult to answer this without more detail, but I'm wondering
why you use EJB at all. For mass data, other approaches are better IMHO.
More precisely IMHO you'll get into problems if you store every single
record of mass data as an EJB. IMHO the overhead is quite high for EJB's
in this scenario. A workable solution might be to just store some
elements as EJBs and let those refer mass data stored in another location.
Regards
robert