Can we configure Trigger on iSeries DB2 table which call AS400 program after transaction commit?
No.
But you can have any changes made by the trigger program happen within the same commit cycle and be commited or rolled back at the same time as the triggering record.
If your trigger program external in RPGLE, make sure to use DFTACTGRP(*NO) ACTGRP(*CALLER) and that you open the files accessed under commitment control.
Detect a commit on the iseries.
monitor the journal RCVJRNE for the commit transaction.
Related
There are two pgms
COBOL CICS (Main PGM) which reads mq queue, triggers transaction and send response back.
Cobol CICS DB2 (Sub PGM) which logs mq details to DB2 table which made in main PGM.
The problem is when at the end of uow, only last inserted data into table(From Sub pgm) were committed but not previously inserted from previous calls.
I tested with explicit commit also but results are same. But if we give syncpoint in PGM 2 which works but eventually collapses other updates done to vsam files from another sub pgms.
Main Pgm (Read MQ, Write MQ) -> Sub Pgm( Logs MQ details (Q/R) to DB2 table) returns control back once inserted.
Any help?
OK -- with EXEC CICS LINK and both programs executing in the same CICS region, then the task automatically has transactionality across all resource managers, MQ as well as Db2. Your program can interfere with this by explicitly issuing the EXEC CICS SYNCPOINT command or the EXEC SQL COMMIT command.
I'm not sure I'm clear on what you mean when you say "triggers the transaction" as an action in your main program. By "transaction" do you mean a unit of work/recovery or do you mean a new CICS task? How is this triggering accomplished?
If your flow is simply:
MQ message arrives
Main program begins execution (triggered by MQ message)
Main program retrieves item from queue
Main program LINKs to subprogram
Subprogram issues INSERT to Db2 table
Subprogram returns to main program
Main program sends MQ reply
Main program retrieves next message from queue
Main program LINKs to subprogram
Subprogram issues INSERT to Db2 table
Subprogram returns to main program
Main program sends MQ reply
-- maybe repeat the GET, LINK, INSERT, RETURN, PUT sequence a couple of times
Main program returns/terminates normally
At this point the Db2 table should have multiple inserted rows.
You could optionally issue a SYNCPOINT/COMMIT after each MQ PUT command to cause the reply to flow immediately and commit the update to the Db2 table. (The original input MQ message is also permanently removed from the queue manager.)
If you are still having a problem with these programs, try asking a colleague to review them to see where you might have introduced an error.
If you think that CICS and/or Db2 are failing, you can open a case to IBM Support to get more assistance.
We have a spring-batch process that uses the bitronix transaction manager. On the first pass of a particular step, we see the expected commit behavior - data is only committed to the target database when the transaction boundary is reached.
However, on the second and subsequent passes, rows are committed as soon as they are written. That is, they do not wait for the commit point.
We have confirmed that the bitronix commit is only called at the expected points.
Has anyone experienced this behavior before? What kind of bug am I looking for?
Java XA is designed in such a way that connections cannot be reused across transactions. Once the transaction is committed, the connection property is changed to autocommit=true, and the connection cannot be used in another transaction until it is returned to the connection pool and retrieved by the XA code again.
Upon client's request, I was asked to turn a web application on read-uncommitted isolation level (it's a probably a bad idea...).
While testing if the isolation was in place, I inserted a row without committing (DBVisualiser : #set autocommit off + stop VPN connection to the database) and I started testing my application towards that uncommitted insert.
select * from MYTABLE WHERE MY ID = "NON_COMMIT_INSERT_ID" WITH UR is working fine. Now I would like to "delete" this row and I did not find any way...
UPDATE : The row did disappear after some time (about 30min). I guess there is some kind of timeout before a rollback is automatically issued. Is there any way to remove an uncommitted row before this happens ?
I think that this will not be possible using normal SQL statements - the only way to delete the row will be to rollback the transaction which inserted it (or wait for tx to commit, then delete). As you have disconnected from DB on network level, then 30 minutes you talk about is probably TCP timeout enforced on operating system level. After TCP connection has been terminated, DB2 rollbacked client's transaction automatically.
Still I think you could administratively force application to disconnect from database (using FORCE APPLICATION with handle obtained from LIST APPLICATIONS) which should rollback the transaction, see http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0001951.htm for details on these commands.
It's one thing to read uncommitted rows from a data base. There are sometimes good reasons (lack of read locks) for doing this,
It's another to leave inserted, updated, or deleted rows on a data base without a commit or roll back. You should never do this. Either commit or roll back after a database change.
JPA is essentially an higher abstraction of JDBC. EntityManager has an API setAutoFlushMode. It can be set to AUTO or COMMIT. What's th equivalent of this in JDBC terms?
thanks
JDBC has auto commit as well.
They're both for configuring whether the library should automatically commit to the database.
JDBCs auto-commit is very simplistic, it will commit every update to the database immediately. Without auto-commit, changes aren't committed until the commit method is called.
JPA AUTO causes a flush to the database before a query is executed. Simple operations like find don't require a flush since the library can handle the search, however queries would be much more complicated, and so if AUTO is set, it will flush it first. If the mode is set to COMMIT, it will only flush the changes to the database upon a call to commit or flush. If COMMIT is set, and a query is run, it will not return results that have not been flushed.
The documentation for set local states:
"Note that SET LOCAL will appear to have no effect if it is executed outside a BEGIN block, since the transaction will end immediately."
If I'm using SET LOCAL in the context of read only transactions do I need to indicate the end of the transaction with a COMMIT statement? Is there any difference if I do this or not?
If your connection is closed without a COMMIT, PostgreSQL will automatically issue a ROLLBACK. In the context of a read only transaction, this has no consequence.
If your connection stays open after your transaction, you might want to issue a ROLLBACK (or a COMMIT, but generally a ROLLBACK is less costly) in order for your next transaction to execute in a clean state.