SAP LUW Memory, DB-Buffer and Commit Questions

[former_member205645]

Hello Gurus,

I've been investigating a problem with a customer made number range; the same number was assigned twice. The DB-Table is fully buffered. In the method that reads the next number there is no COMMIT WORK and that is right, because the method is being called in a LUW that must not be disturbed. While debugging I have noticed that although there is no COMMIT, the SE16N was displaying in another mode(right after MODIFY) the modified data. After interrupting the debugger it must have executed a ROLLBACK because the data was "deleted".

On top of that, we also have two application servers and I know that the buffer syncronization only checks about every 1-2 minutes to see if there are differences between the buffers.

The questions are :  1. How does the Memory(where is the data that has to be written in the DB?) in a SAP LUW work?

                                 2. How does the DB-Buffer management work?

                                 3. Does the new debugger have implicit commits?

                                 4. Would it be possible that the problem are the two buffers in the two separate application servers (I hope not )

Regards,

Ioan.

P.S. please no sap help links I have already read that

[Former Member]

Hi Ioan.

As described in SAP note 179224 if you have several application servers you should have switched the number range object to local buffer mechanism. This is to use NRIV_LOKAL instead of NRIV.

Please check your number range in SNRO to be customized as in the SAP note described.

Regards,

Klaus

[former_member205645]

Hi Klaus,

thank you very much for the reply. I forgot to mention; we have our own Z-Table. That is what I meant with "the table is fully buffered". I'm sorry for that.

Regards,

Ioan.

[Former Member]

Hi Ioan,

but you need a custom number range object or a special lock mechanism for your table to avoid duplicates. I've thought that you use your own custom number range object.

Anyway you have to avoid two parallel processese that want too update your table.

You can also lock the complete table for update if one process ask for a new number. If the table is locked you have to deny a new number for the second process.

Or you can use SAP standard fm NUMBER_GET_NEXT if you use your own custom number range object.

Regards,

Klaus 

[former_member205645]

Hello Klaus,

the mechanism was wrote by a colleague(he is no longer here) some time ago. Everything is new customer development. There is a Z_ table that constains the numbers that have to be allocated and there is a Z_ class and method that locks, reads and marks a number as "used".

I have used the term "number range" because that is the concept, but like I've mentioned, everything is customer development because of an external server(HOST) that manages the numbers.

I don't know why they didn't use na external number range.

Regards,

Ioan.

[former_member205645]

I have tested it. The synchronizing of the buffer between the two application servers is working fine.

And the new debugger does/should not heva implicit commits.