uncontrolled performed rollbacks

[cugar]

Hi there,

just got a few problems with the transaction rollback functionality of openege 10.1A.

1. discovered problem complete transactions disappeard or have not been performed to the database - there hasn't been any applycation crash at this time. --> for that i tried the -nosavepoint qualifier
2. discovered problem (occures with and without -nosavepoint).
user interface crashes and the work eg. of an hour or two gets rolledback.

Fact is the user is working the whole time with the same window calling different subroutines (dynamic buttons). Tried with exclusive locks instead of shared locks - no change (only the number of locks was cut down, 'cause it seemed to me that some shared-locks have not been released after updating even with releasing the table).

yesterday i've lost 100+ entries (also in the audit-table) and i don't know how to prevent the application to do so......

any idea?`

thanx cugar

 

[TomBascom]

1) This has nothing to do with your actual problem but you should upgrade to 10.2. 10.1A is getting long in the tooth.

2) This has nothing to do with -nosavepoint. You have a transaction active somewhere very high up in the chain of programs being run. Probably in the main program. You should carefully review your transaction scoping. You might start by compiling your main program with the LISTING option and taking a look at what it has to say about where transactions are scoped.

3) I'm just guessing but are you, perhaps, coming from a SQL oriented background where transactions must be explicitly committed? Progress isn't like that. Progress implicitly starts and commits transactions. The rules are fairly simple but they take some adjustment.

 

[cugar]

yes indeed i'm used to code with "usual" SQL-Based Transaction-handling and error-handling.

I was very suprised when i first saw the defferences between .net programming and progress....

but i suppose i've found the problem. The code itself uses a couple of widget-pools for dynamic button assignment. As I've seen one widget-pool has been defined in the main window as well as in a later used windos. I've just noticed as i tried to delete the widget-pool for cleaning up.

This could be the reason for the locks wich are only released when the whole appl is closed. Could this also be the reasion why the transaction called by an button widget within the widged-pool won't complete? just renamed the pool and did a delete before the widget-pool is recreated and refilled.....

might be a solution?

update:

just poke with the comp. delivering the inital code for the appl why they are still using 10.1A - as they told me they are only updating on mayor releases - lets take a look if my boss has a different opinion....

 

[GregTomkins]

I don't think widget pools have any bearing on transaction scoping... Tom?

 

[cugar]

even when the widget pool is created a 100 times with no deletion?

 

[GregTomkins]

Well I guess if you created it enough times maybe it would crash the P4GL client and that would certainly have an impact. But I don't think 100x would scratch the surface. We had a problem years ago where we were neglecting to clean up large TT's 1000's of times and nothing crashed.

 

[cugar]

well it looks like that the progress-client is crashing or restarting (like pressing ctrl+pause)

 

[TomBascom]

The widget pool has nothing to do with transaction scope.

Too much memory use might crash the client which would lead to transaction rollback but but it isn't the root cause of rolling back more data than expected. Just defining widget pools wouldn't cause that either.

Examining the transaction scope is what needs to happen here. Without a look at the code it is difficult to say much more. Compiling with the LISTING option is your friend.

BTW -- if you can compile code you can upgrade. It doesn't matter how often your vendor releases their stuff. Even if you cannot compile all of the code you can probably upgrade -- r-code stays compatible until the major release number changes. But I'd be curious to know what their reasoning is for sticking with an unsupported release of Progress. My guess is that they are simply ignorant.

 

[cugar]

well it is allready possible to say that the ammount of locks has decreased (just defined a do transaction on clicking the button and releasing the widget-pool...)

i'm not quite shure if this is the solution - but it looks like it has to do something with that...

listening-option of compiler:

well i do get a file but it looks more like a copy of the running sourcecode - are therey any hidden information?

additional information:

just tried the option view transaction (debugger):

looks like that no transactions are active after clicking the button and doing all things that are needed...... as far as i know -> completed transaction can't be rolled back - don't they?

 

[GregTomkins]

I think the "defining a transaction" part is highly relevant, and the "widget pool" part is not. Widget-pool is about automatically releasing memory associated with dynamically created objects, and has nothing (that I can think of) to do with database records and transactions, etc.

 

[cugar]

okay great thanks - i'll tell you about the results......


btw.:

i'll need to connect the progress-db with a c# coded software. afaik the odbc-connector not uses all possibilities of the db and the performance is pretty poor - any 3rd party products or other suggestions?

thank you for info.....

regards

cugar

 

[GregTomkins]

Geez that's a loaded question. My personal opinion is that C# is the way to go for GUI front end and Progress is the way to go for back end database and business stuff. The two could communicate several ways but the most obvious and IMO best way is via .NET proxies and AppServers. We do this all the time and it works great, good performance etc.

Some alternatives are ODBC (perhaps slow, and much worse, generally implies too much business logic in the C# front end), sockets (ugh), Web Services (if you like turning a 15 byte request into 25 MB of XML verbiage)... no doubt there are a few others.

If you are putting business logic in C# and just using Progress as a data store, well then, the only reason I would see to do that is if you are tied to Progress due to a legacy app. For anything new, just use some cheap SQL database instead, the value of Progress is the 4GL, not the database.

 

[TomBascom]

Transactions that are committed won't rollback.

But DO TRANSACTION... might just be a sub-transaction. You won't get a compile warning if the issue only arises at runtime due to the calling procedure already having a TRX active.

/* trx0.p */
find first customer.
update name.
run trx1.p.
pause.

/* trx1.p */
find last customer.
discount = 15.
return.

compile trx0.p listing trx0.lis

./trx0.p                              06/18/2009 12:00:15   PROGRESS(R) Page 1

{} Line Blk
-- ---- ---
      1     find first customer.
      2     update name.
      3     run trx1.p.
      4     pause.
^L./trx0.p                              06/18/2009 12:00:15   PROGRESS(R) Page 2

     File Name       Line Blk. Type   [COLOR="DarkOrange"]Tran[/COLOR]            Blk. Label
-------------------- ---- ----------- ---- --------------------------------
[B][COLOR="Red"]./trx0.p                0 Procedure   Yes[/COLOR][/B]
    Buffers: sports2000.Customer
    Frames:  Unnamed

When you run this code if you type ^C at the PAUSE statement the transaction that you think you committed in trx1.p is rolled back.

That happens because, at runtime, there is a transaction active when trx1 is run and that larger transaction gets rolled back by the ^C.

 

[TomBascom]

BTW -- the sample code above is vile. You shouldn't be coding like that

 

[tamhas]

The key here is to follow Tom's suggest to use the compile with listing option and look at where it tells you there are transaction blocks. You are certain to find the scope is much higher than you want it to be. A common cause is a buffer scoped to a higher level than you expect. You can tell that from the listing too. The solution is to wrap block with explicit scope, i.e., DO FOR CUSTOMER: You can also add the transaction keyword to blocks, but if you are already inside a transaction, that will get you a compile error.

 

[cugar]

okay got the listening file....

WOW what the hell is that....

using those smart-windows causes really a lot of blocks.....

example:

File Name Line Blk. Type Tran Blk. Label
-------------------- ---- --------- ---- --------------------------------
...c\adm2\cntnprto.i 1 Procedure No Procedure assignPageProperty
...c\adm2\cntnprto.i 34 Procedure No Procedure changePage
...c\adm2\cntnprto.i 37 Procedure No Procedure confirmExit
...c\adm2\cntnprto.i 41 Procedure No Procedure constructObject
...c\adm2\cntnprto.i 48 Procedure No Procedure createObjects
...c\adm2\cntnprto.i 51 Procedure No Procedure deletePage
...c\adm2\cntnprto.i 55 Procedure No Procedure destroyObject
...c\adm2\cntnprto.i 58 Procedure No Procedure hidePage
...c\adm2\cntnprto.i 62 Procedure No Procedure initializeObject
...c\adm2\cntnprto.i 65 Procedure No Procedure initializeVisualContainer
...c\adm2\cntnprto.i 68 Procedure No Procedure initPages
...c\adm2\cntnprto.i 72 Procedure No Procedure notifyPage
...c\adm2\cntnprto.i 76 Procedure No Procedure passThrough
...c\adm2\cntnprto.i 81 Procedure No Procedure removePageNTarget
...c\adm2\cntnprto.i 86 Procedure No Procedure selectPage
...c\adm2\cntnprto.i 90 Procedure No Procedure toolbar
...c\adm2\cntnprto.i 94 Procedure No Procedure viewObject
...c\adm2\cntnprto.i 97 Procedure No Procedure viewPage
...rc\adm2\visprto.i 1 Procedure No Procedure applyLayout
...rc\adm2\visprto.i 32 Procedure No Procedure disableObject
...rc\adm2\visprto.i 35 Procedure No Procedure enableObject
...rc\adm2\visprto.i 38 Procedure No Procedure initializeObject
...rc\adm2\visprto.i 41 Procedure No Procedure processAction
...c\adm2\appsprto.i 1 Procedure No Procedure bindServer
...c\adm2\appsprto.i 32 Procedure No Procedure destroyObject

 

[cugar]

just an update:

today looks better but not perfect......

i'll try to catch after each block if there is still a transaction active and write it into a log-file maybe i'll get the answer for the my riddle....

 

[tamhas]

Yes, you can use the TRANSACTION keyword in the code to test if one is active.

Don't forget that one of the most common reasons for this sort of behavior is starting a transaction and then calling an otherwise well-behaved subprogram which would ordinarily do a whole bunch of separate transactions, but, since a transaction is already started, it bundles them all into one.

BTW, this might also show up in your use of locks. A bit of wandering around promon or ProTop might help reinforce the diagnosis.

It all reminds me of the old Varnet code where there was an option to press a help key and leap out to another program from within a running program. If the other program was something like an inquiry and one found what one wanted and came back, all was well. But, when people did something like assign Order Entry to one of those keys and leap out from the middle of Customer Maintenance, they were, of course, already in a transaction because those old programs were all written as direct updates to a database buffer. Occasionally, someone would do this and then forget they had done it and proceed from the first order to do a whole morning's work in Order Entry. Then they would hit F4 to exit and find themselves in Customer Maintenance again. If they were lucky, they would hit F1 to complete the update and all would be fine, but all too often they would F4 to get out of Customer Maintenance ... and undo the entire morning's work!