LiveCycle Transactions (or lack thereof)

[Ryan Lunka]

On my current enterprise-level LiveCycle implementation we are running
into some significant, but interesting issues, regarding the lack of
transactions in LiveCycle ES. This specifically becomes an issue with
regards to data base inserts/updates. I'm curious how some of you
have address these issues in the past. I know one solution, which we
are looking at heavily, would be to use custom Java components that
would wrap up all the database calls into one step of the workflow,
but I still see holes in the idea. Plus, it essentially undermines
the functionality of LiveCycle and makes our application a Java
application.

Does anyone have any thoughts, suggestions, failed/successful attempts
to solve this problem, or ideas?

[JYates]

Have you read the documentation for "short-lived" processes? There is
some control over the transactional state of the process (right-click
your process and select 'properties' then click the Advanced tab). If
the documentation shows that level of transaction control will be
sufficient for you, you can put each JDBC call into a stand-alone
short-lived process. Then in your main process you can call the
wrapper process instead of the JDBC component directly.

The only other approach that comes to mind is to build your own JDBC
component (someone may have another way, but I haven't come up with
anything in just a couple minutes brainstorming). This is encouraged
by Adobe in fact, they consider things like the JDBC Component they
provide to be only starting points. We at Avoka have built a library
of Components that go a couple steps farther than some of the built-in
Components, as well as wholly new functionality. Unfortunately our
SQL related Components don't add any more transactional control than
the built-in Adobe Component.

It is a somewhat complex situation, as long-lived processes are
wrapped in a specific transactional situation by the LiveCycle engine.
(That's why you can't change the transaction properties of a long-
lived process, only the short-lived.) But if you build your own, you
can tailor it for your application server/database server combo and
should be able to make it work.

Sorry there isn't more to my answer.

J Yates
Avoka Technologies
www.avoka.com

[Srini Dhulipalla]

Hi JYates,
We are also having the similar issue but made it work with the
short-lived process. But the other issue we have is the short-lived
process does not store any info to the LiveCycle database. In our case
the users should be able to query the database based on a task id or
process id. Is there a way to control the LC transactions by still
keeping the process as long-lived? Any help you provide is greatly
appreciated.

Thanks
Srini

[WorkbenchWriter]

How about using a transactional branch in a gateway?

[Duane Nickull]

I think that Avoka has written a component that does this.  It shouldn’t be that hard to build such a component and deploy it to LC ES that can be queried for state.


Private data members (State TransactionState, Boolean LastComplete, Boolean completed, ... Etc)

As long as you can query it for it’s state or potentially register call back handlers for various events like timeouts, stalls, etc it should do what you want.

Of course, this is not the same for every user but there should be some commonalities.

Duane

--
Adobe LiveCycle Enterprise Architecture - http://www.adobe.com/products/livecycle/
Twitter – duanechaos
Blog – http://technoracle.blogspot.com/

[Ryan Lunka]

Thanks for the reponse...very detailed. As a matter of fact on the
current project I'm on, I do wrap each individual JDBC call in it's
own service, so yes, if that one breaks the entire SQL statement is
undone. The problem is, that on a larger scale you don't have that
transaction luxury. Say I have have individual process all with a
single JDBC call and I want all or none of them to execute. If say
the second JDBC call fails, the first will still be committed to the
database, which in essence is where transactions break down in out-of-
the-box LC functionality.

We've already been addressing the possibility (read probability) of
using a custom JDBC component. I was just interested to hear if
anyone had any creative solutions to the issue, besides that.

On Oct 21, 8:33 am, JYates <jya...@primaryfunction.com> wrote: