Rails, EJBs and transaction control.

Hi folks,

Let me ask for a little help. I would like to know how this situation
could be handled in Rails.

Here is the point: I have an application (Java nowadays) that uses two
master resources: a Data base and an ECM

In situations like that, generally the user selects the document to be
stored (PDF, IMAGE, DOC, etc), the application stores it in the ECM,
getting the DOC_ID, and writes a DOC_ID reference in the database in
one or more of the business model tables.

And here comes the problem. There is not a unified transaction control
between the database and the ECM.

Theoretically the act of writing in the ECM and the act of writing in
the database should be under the control of the same transaction. Any
problem and EVERYTHING should be undone.

In Java, that is easy, well, better to say feasible, because the
solution was using EJBs. I have created an EJB for each writing, one
EJB for writing in the ECM and other for writing in the database, and
a third to group the previous two. That way, this third EJB becomes
responsible to the whole transaction control.

How could it be done in Rails? Should I control it manually? Or does
Rails have any kind of transaction control container that can handle

In this example, if something goes wrong in the last writing action
(which depends on how the ECM works), the first writing action should
be undone by the application?


Hi folks,

No answers at all?

Please quote when replying.

MarcRic wrote in post #955406:

Hi folks,

No answers at all?

I doubt that too many people on this list have experience with the sort
of distributed transaction control that you're describing -- I know I
don't. If I had to do something like this in Rails, I'd probably have
an included module that extended AR subclasses to communicate with the
ECM system. This would probably handle the ECM I/O and any transaction
coordination necessary.

But I'm just guessing here. What I'd really do would be write some
tests (WebMock would be useful here) and start playing around!

Also, you might get better advice on the main Ruby list.