Last updated on DECEMBER 25, 2010
Applies to:
Oracle Communications Billing and Revenue Management - Version: 7.3.0.0.1Information in this document applies to any platform.
Symptoms
PCM_OP_SUBSCRIPTION_SET_DISCOUNT_STATUS opcode is encapsulated into a custom opcode. When the custom opcode is called, PCM_OP_SUBSCRIPTION_SET_DISCOUNT_STATUS is called to change the status from 1 to 2. After the call, check the results using a READ_OBJ and the status is still 1.Steps to reproduce:
r << XXX 1
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 1
0 PIN_FLD_AAC_ACCESS STR [0] "CACHEABLE_WRITE"
XXX
r << XXX 2
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 1
0 PIN_FLD_AAC_ACCESS STR [0] "NON_CACHEABLE_WRITE"
XXX
r << XXX 3
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 1
0 PIN_FLD_AAC_ACCESS STR [0] NULL
XXX
# Open transaction
open rw 1
# Cacheable write
xop PCM_OP_WRITE_FLDS 0x0400 1
# Non-Cacheable write
xop PCM_OP_WRITE_FLDS 0 2
# Read it back
xop PCM_OP_READ_FLDS 0 3
commit
# Read it back again
xop PCM_OP_READ_FLDS 0 3Which gives the following output:
xop: opcode 5, flags 1024
# number of field entries allocated 20, used 1
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 1 0
xop: opcode 5, flags 0
# number of field entries allocated 20, used 1
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 1 0
xop: opcode 4, flags 0
# number of field entries allocated 20, used 2
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 1 0
0 PIN_FLD_AAC_ACCESS STR [0] "NON_CACHEABLE_WRITE"
xop: opcode 4, flags 0
# number of field entries allocated 20, used 2
0 PIN_FLD_POID POID [0] 0.0.0.1 /account 1 13
0 PIN_FLD_AAC_ACCESS STR [0] "CACHEABLE_WRITE"
You can see that before the commit, the NON_CACHEABLE_WRITE is correct (it's gone direct to the database). When the transaction is committed, the cached version is flushed and it ends up with incorrect data.
Cause
Sign In with your My Oracle Support account |
|
Don't have a My Oracle Support account? Click to get started |
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms