This content has been marked as final. Show 5 replies
XLA is a 'post commit' API. Changes are only delivered via XLA after the transaction that makes the change has comitted its changes in TimesTen. Hence andy change delivered by XLA represents an already comitted change. If a transaction changes an XLA tracked table but then gets rolled back instead of being comitted then nothing will be notified via XLA.
Note that XLA is asynchronous to the actual application transactions. So consider the following sequence:
Application inserts row '1' and commits at time T1.
Application deletes row '1' and commits at time T3.
The XLA notfication will be delivered to anyone listeneing for changes to this table at some time T2 which is >= T1. However, depending on the val;ue of T3 - T1, system load, wheteher the XLA application is processing quiockly enough to 'keep up' etc. It may be that T2 >= T3 in which case by the time that XLA gets the notification the row has already been deleted again by the application.
I'm not saying this is what is happenning in your case but am just illustrating how XLA works. You need to be sure to take this into account when using it.
Thanks for replying.
In our case T2 comes between T1 and T3
We were using the same application code for the previous versions of Timesten and we never come across this issue earlier.
We would like to know if there is any change in the current release (TimesTen Release 18.104.22.168.0 (64 bit Linux/x86_64)) on XLA behavior.
What was the previous release that you were using? There should not be any fundamerntal behaviour change in XLA between releases other than due to bug fixes etc.
Can you provide more detail on what your XLA application codel looks like? Presumably it checks that the operation is indeed an insert rather than reacting to any change on the table? To diagnose this kind of thing we really need the application XLA code to examine the logic plus a description of the transaction pattern on the table in question.
Earlier Timesten version: 22.214.171.124.0
1. Application A inserts a record
2. Application B
a. receive XLA trigger
b. reads the data and does the application logic
c. deletes the data from the table.
Even though XLA is triggered, we are not finding record in the table where XLA is configured.
There should not be any changes at the XLA level that would affect application behaviour, but for sure there are a great many major changes in 11.2.1 compared to 7.0 many of which may affect application behaviour. Are you sure this is not a non-XLA issue?
You need to open an SR for this I think. We will almost certainly want to see your application source code (for the XLA reader) if possible.