Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

updates committed on fatal error

4 posts in General Discussion (old) Last posting was on 2000-02-16 16:06:33.0Z
Martyn Evans Posted on 2000-02-15 14:47:59.0Z
Newsgroups: sybase.public.easerver
From: "Martyn Evans" <martyne@iplbath.com>
Subject: updates committed on fatal error
Date: Tue, 15 Feb 2000 14:47:59 -0000
Lines: 30
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
NNTP-Posting-Host: h1.iplbath.com 195.153.211.7
Message-ID: <347_GvXmuQ8d$GA.223@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28661
Article PK: 160791

Hi,

We have a pb client application that uses pb components deployed to Jaguar.
We have noticed that if we have a fatal exception mid-way through a
transaction, updates already performed on that transaction are being
committed.

I have a stateful transaction object through which I create a component and
call an Update() function, passing two blobs. The first blob is processed
and the changes made.. as a test I then deliberately cause a fatal error (by
indexing outside of an array). The error is marshalled back to the client
OK, the object disappears and is not pooled - though its deactivate,
canbepooled and destructor events are not triggered (I assume this is
correct behaviour?).

The transaction object remains and times out. However, it seems that the
connection is being left in a dubious state.. the next time that that
connection is used (i.e when I re-start the application) the previous
changes are committed??

Have I missed an option somewhere? or do we need to add further error
handling to roll-back the transaction? we are using pb7.0.2 and Jag 3.5
with Oracle 7.3.

thanks

Martyn


Carson Hager[Team Sybase] Posted on 2000-02-15 16:03:13.0Z
Newsgroups: sybase.public.easerver
From: chager@dyn-data.com (Carson Hager[Team Sybase])
Subject: Re: updates committed on fatal error
Date: Tue, 15 Feb 2000 16:03:13 GMT
Organization: Dynamic Data Solutions, Inc.
X-Newsreader: Forte Free Agent 1.21/32.243
Lines: 54
NNTP-Posting-Host: 63.86.26.206
Message-ID: <347_38a978ae.33745593@forums.sybase.com>
References: <347_GvXmuQ8d$GA.223@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28660
Article PK: 160794

What transactional settings do you have for your components that you
are using?


Carson

___________________________________________________________

Carson Hager
Team Sybase
Dynamic Data Solutions, Inc.
Enterprise Application Studio 3.0 Consulting and Training
http://www.dyn-data.com

DDS is now hiring EAServer consultants
to support its exploding EAServer business!
Please submit your resume to
hr@dyn-data.com!


On Tue, 15 Feb 2000 14:47:59 -0000, "Martyn Evans"

<martyne@iplbath.com> wrote:

>Hi,
>
>We have a pb client application that uses pb components deployed to Jaguar.
>We have noticed that if we have a fatal exception mid-way through a
>transaction, updates already performed on that transaction are being
>committed.
>
>I have a stateful transaction object through which I create a component and
>call an Update() function, passing two blobs. The first blob is processed
>and the changes made.. as a test I then deliberately cause a fatal error (by
>indexing outside of an array). The error is marshalled back to the client
>OK, the object disappears and is not pooled - though its deactivate,
>canbepooled and destructor events are not triggered (I assume this is
>correct behaviour?).
>
>The transaction object remains and times out. However, it seems that the
>connection is being left in a dubious state.. the next time that that
>connection is used (i.e when I re-start the application) the previous
>changes are committed??
>
>Have I missed an option somewhere? or do we need to add further error
>handling to roll-back the transaction? we are using pb7.0.2 and Jag 3.5
>with Oracle 7.3.
>
>thanks
>
>Martyn
>
>
>

___________________________________________________________

Carson Hager
Team Sybase
Dynamic Data Solutions, Inc.
Enterprise Application Studio 3.0 Consulting and Training

DDS Enterprise Application Framework
Available Now as Open Source!
http://www.dyn-data.com


Martyn Evans Posted on 2000-02-15 17:45:03.0Z
Newsgroups: sybase.public.easerver
From: "Martyn Evans" <martyne@iplbath.com>
Subject: Re: updates committed on fatal error
Date: Tue, 15 Feb 2000 17:45:03 -0000
Lines: 104
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
NNTP-Posting-Host: h1.iplbath.com 195.153.211.7
Message-ID: <347_7bvrxz9d$GA.332@forums.sybase.com>
References: <347_GvXmuQ8d$GA.223@forums.sybase.com> <347_38a978ae.33745593@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28640
Article PK: 160773

Carson,

The transaction object (A) 'requires new', the object on which I perform the
updates (B) is marked as 'supports'. Object A has autoDemarcation off,
concurrency and Bind Thread on. Object B has autodemarcation, concurrency
and bind thread on. Neither object supports pooling as default - we have
implemented pooling programmatically using the canbepooled event.

After further investigation I think I have discovered the problem.. I did
not have any code in the systemerror event of the application I use to build
and deploy the pb components to jaguar. Once I scripted this (I just put
some debug in to see if it was called) the deactivate, canbepooled and
destructor events of object B were then fired correctly and the connection
cleared up fine = no data committed!

This is great.. but Im not sure why this should make a difference? Is this
correct behaviour?

The reason I had no script was because I have previously had problems making
the systemerror event fire (we have perhaps upgraded a few times since
then.. was there ever a problem?), and was even doubtful that it should be
called? Can I now guarantee that it will be called when a fatal error
occurs?

Sorry to bombard you with questions!

many thanks

Martyn

Carson Hager[Team Sybase] wrote in message
<38a978ae.33745593@forums.sybase.com>...
>What transactional settings do you have for your components that you
>are using?
>
>
>Carson
>
>___________________________________________________________
>
>Carson Hager
>Team Sybase
>Dynamic Data Solutions, Inc.
>Enterprise Application Studio 3.0 Consulting and Training
>http://www.dyn-data.com
>
> DDS is now hiring EAServer consultants
> to support its exploding EAServer business!
> Please submit your resume to
> hr@dyn-data.com!
>
>
>On Tue, 15 Feb 2000 14:47:59 -0000, "Martyn Evans"
><martyne@iplbath.com> wrote:
>
>>Hi,
>>
>>We have a pb client application that uses pb components deployed to
Jaguar.
>>We have noticed that if we have a fatal exception mid-way through a
>>transaction, updates already performed on that transaction are being
>>committed.
>>
>>I have a stateful transaction object through which I create a component
and
>>call an Update() function, passing two blobs. The first blob is processed
>>and the changes made.. as a test I then deliberately cause a fatal error
(by
>>indexing outside of an array). The error is marshalled back to the client
>>OK, the object disappears and is not pooled - though its deactivate,
>>canbepooled and destructor events are not triggered (I assume this is
>>correct behaviour?).
>>
>>The transaction object remains and times out. However, it seems that
the
>>connection is being left in a dubious state.. the next time that that
>>connection is used (i.e when I re-start the application) the previous
>>changes are committed??
>>
>>Have I missed an option somewhere? or do we need to add further error
>>handling to roll-back the transaction? we are using pb7.0.2 and Jag 3.5
>>with Oracle 7.3.
>>
>>thanks
>>
>>Martyn
>>
>>
>>
>
>
>___________________________________________________________
>
>Carson Hager
>Team Sybase
>Dynamic Data Solutions, Inc.
>Enterprise Application Studio 3.0 Consulting and Training
>
> DDS Enterprise Application Framework
> Available Now as Open Source!
> http://www.dyn-data.com
>


Martyn Evans Posted on 2000-02-16 16:06:33.0Z
Newsgroups: sybase.public.easerver
From: "Martyn Evans" <martyne@iplbath.com>
Subject: Re: updates committed on fatal error
Date: Wed, 16 Feb 2000 16:06:33 -0000
Lines: 145
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
NNTP-Posting-Host: h1.iplbath.com 195.153.211.7
Message-ID: <347_HMD1QhJe$GA.332@forums.sybase.com>
References: <347_GvXmuQ8d$GA.223@forums.sybase.com> <347_38a978ae.33745593@forums.sybase.com> <347_7bvrxz9d$GA.332@forums.sybase.com>
Path: forums-1-dub!forums-1-dub!forums-master.sybase.com!forums.sybase.com
Xref: forums-1-dub sybase.public.easerver:28564
Article PK: 160707

I have pinned the problem down further and now think there is possibly a
bug.

The original problem of the data being committed was because the deactivate
event was not being fired, leaving updates pending on a connection which was
then being returned to the cache (and committed when the connection was next
used). Trying to determine why the deactivate event was not fired has
turned up some interesting results :

When we have a fatal error in a server component we nornally expect the
deactivate, canbepooled and destructor events to be fired. This happens
fine with components that do not support transactions, and even ok with
components that support transactions and either have not performed any
updates, or have SetComplete/SetAbort. However, a fatal error in a
component that has performed an update that has not yet been committed (i.e
after calling update() on the datastore) does NOT result in the
deactivate/CanBePooled/destructor events being fired - the component just
stops.

Anyway, for whatever reason scripting the systemerror event in the
application used to deploy the pb components seems to be a workaround.
Having ANY code (even just a one line comment!) appears to ensure that the
deactivate/canbepooled/destructor events are called correctly after a fatal
error occurs when an update is pending. In all other cases the systemerror
event is NOT triggered, which is what I expect.

Unless anyone can shed any light on this behaviour I will report it as a
bug...??

Thanks

Martyn

Martyn Evans wrote in message <7bvrxz9d$GA.332@forums.sybase.com>...
>Carson,
>
>The transaction object (A) 'requires new', the object on which I perform
the
>updates (B) is marked as 'supports'. Object A has autoDemarcation off,
>concurrency and Bind Thread on. Object B has autodemarcation, concurrency
>and bind thread on. Neither object supports pooling as default - we have
>implemented pooling programmatically using the canbepooled event.
>
>After further investigation I think I have discovered the problem.. I did
>not have any code in the systemerror event of the application I use to
build
>and deploy the pb components to jaguar. Once I scripted this (I just put
>some debug in to see if it was called) the deactivate, canbepooled and
>destructor events of object B were then fired correctly and the connection
>cleared up fine = no data committed!
>
>This is great.. but Im not sure why this should make a difference? Is this
>correct behaviour?
>
>The reason I had no script was because I have previously had problems
making
>the systemerror event fire (we have perhaps upgraded a few times since
>then.. was there ever a problem?), and was even doubtful that it should be
>called? Can I now guarantee that it will be called when a fatal error
>occurs?
>
>Sorry to bombard you with questions!
>
>many thanks
>
>Martyn
>
>Carson Hager[Team Sybase] wrote in message
><38a978ae.33745593@forums.sybase.com>...
>>What transactional settings do you have for your components that you
>>are using?
>>
>>
>>Carson
>>
>>___________________________________________________________
>>
>>Carson Hager
>>Team Sybase
>>Dynamic Data Solutions, Inc.
>>Enterprise Application Studio 3.0 Consulting and Training
>>http://www.dyn-data.com
>>
>> DDS is now hiring EAServer consultants
>> to support its exploding EAServer business!
>> Please submit your resume to
>> hr@dyn-data.com!
>>
>>
>>On Tue, 15 Feb 2000 14:47:59 -0000, "Martyn Evans"
>><martyne@iplbath.com> wrote:
>>
>>>Hi,
>>>
>>>We have a pb client application that uses pb components deployed to
>Jaguar.
>>>We have noticed that if we have a fatal exception mid-way through a
>>>transaction, updates already performed on that transaction are being
>>>committed.
>>>
>>>I have a stateful transaction object through which I create a component
>and
>>>call an Update() function, passing two blobs. The first blob is
processed
>>>and the changes made.. as a test I then deliberately cause a fatal error
>(by
>>>indexing outside of an array). The error is marshalled back to the
client
>>>OK, the object disappears and is not pooled - though its deactivate,
>>>canbepooled and destructor events are not triggered (I assume this is
>>>correct behaviour?).
>>>
>>>The transaction object remains and times out. However, it seems that
>the
>>>connection is being left in a dubious state.. the next time that that
>>>connection is used (i.e when I re-start the application) the previous
>>>changes are committed??
>>>
>>>Have I missed an option somewhere? or do we need to add further error
>>>handling to roll-back the transaction? we are using pb7.0.2 and Jag 3.5
>>>with Oracle 7.3.
>>>
>>>thanks
>>>
>>>Martyn
>>>
>>>
>>>
>>
>>
>>___________________________________________________________
>>
>>Carson Hager
>>Team Sybase
>>Dynamic Data Solutions, Inc.
>>Enterprise Application Studio 3.0 Consulting and Training
>>
>> DDS Enterprise Application Framework
>> Available Now as Open Source!
>> http://www.dyn-data.com
>>
>
>