MyPortal issue, service error in one portlet causes stack trace in a different portlet

[James McGill-5]

I make two portlets.  One of them calls a service.  If that service has an
error, it causes another portlet to render a stack trace.

I put steps to reproduce in a Jira ticket.

https://issues.apache.org/jira/browse/OFBIZ-3903

This is 9.04.  Maybe I'm just doing something wrong.  Is there some way to
flush the dispatcher?  I hope someone can look at this and explain what's
going on.

--
James McGill
Phoenix AZ

[James McGill-5]

On Thu, Aug 26, 2010 at 2:43 PM, James McGill <
[hidden email]> wrote:

>
> https://issues.apache.org/jira/browse/OFBIZ-3903
>
>
I found that by adding TransactionUtil.rollback(); after seeing an error
result from the Dispatcher, I can at least hide the problem.


--
James McGill
Phoenix AZ

[David E. Jones-2]

On Aug 26, 2010, at 5:13 PM, James McGill wrote:

> On Thu, Aug 26, 2010 at 2:43 PM, James McGill <
> [hidden email]> wrote:
>
>>
>> https://issues.apache.org/jira/browse/OFBIZ-3903
>>
>>
> I found that by adding TransactionUtil.rollback(); after seeing an error
> result from the Dispatcher, I can at least hide the problem.

It looks like you're getting into why this happens. Screen rendering is done within a big single transaction. If you want parts of the screen to fail independently of other parts of the screen, they need to be in a separate transaction (ie pause the original, start new, commit/rollback new, resume original). Just rolling back a failed transaction and leaving the rest of the screen hanging is probably not a good idea.

-David

[Scott Gray-2]

On 27/08/2010, at 11:25 AM, David E Jones wrote:

> On Aug 26, 2010, at 5:13 PM, James McGill wrote:
>
>> On Thu, Aug 26, 2010 at 2:43 PM, James McGill <
>> [hidden email]> wrote:
>>
>>>
>>> https://issues.apache.org/jira/browse/OFBIZ-3903
>>>
>>>
>> I found that by adding TransactionUtil.rollback(); after seeing an error
>> result from the Dispatcher, I can at least hide the problem.
>
> It looks like you're getting into why this happens. Screen rendering is done within a big single transaction. If you want parts of the screen to fail independently of other parts of the screen, they need to be in a separate transaction (ie pause the original, start new, commit/rollback new, resume original). Just rolling back a failed transaction and leaving the rest of the screen hanging is probably not a good idea.
>
> -David

Perhaps we should add a require-new-transaction attribute to the screen element?

Regards
Scott