JDBCStoreManager.releaseConnection causes rollback???

I thought that getting the SQL connection from PersisientManager would allow
me to do
JDBC stuff on the same connection and in the same transaction. But I cannot
get SQL updates
to 'persist' without calling commit on the transaction.
Is this a bug, user error, or as designed. If any oh the last two, how
can I do db updates through JDBC and have them being tied to the same
transaction as the PM's transaction (and commit when it commits)?
Below is a test program where I expected the number of rows returned to be
1, but
it returns zero.
Thanks,
Eivind Skildheim
Motive Communications, Inc
import java.io.File;
import java.io.FileInputStream;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager;
import com.solarmetric.kodo.runtime.PersistenceManagerImpl;
public class KodoTest
public static void main(String[] args)
try
Properties props = new Properties();
props.load(new FileInputStream(args[0]));
PersistenceManagerFactory pmf =
JDOHelper.getPersistenceManagerFactory (props);
PersistenceManager pm = pmf.getPersistenceManager();
pm.currentTransaction().begin();
JDBCStoreManager sm = getStoreManager(pm);
Connection conn = sm.getConnection();
Statement stmt = conn.createStatement();
stmt.executeUpdate("create table foo(bar number not null)");
stmt.executeUpdate("insert into foo(bar) values(1)");
sm.releaseConnection(conn);
conn = sm.getConnection();
stmt = conn.createStatement();
ResultSet row = stmt.executeQuery("select count(*) from foo");
row.next();
getLogger().info("Number of rows = " + row.getInt(1));
sm.releaseConnection(conn);
System.exit(0);
catch(Throwable e)
getLogger().error("", e);
System.exit(1);
private static JDBCStoreManager getStoreManager(PersistenceManager pm)
return (JDBCStoreManager)
((PersistenceManagerImpl)pm).getStoreManager();
private static Log getLogger()
return LogFactory.getLog(KodoTest.class);

Eivind-
This is as designed: the PersistenceManager allocates Connections on an
as-needed basis, so obtaining a connection from it will not be part of
the PersistenceManager's transaction process.
Instead, what you can do is to use the SQLExecutionListener interface
to execute some SQL in the beforeCommit() phase. E.g., you can do:
     JDBCStoreManager sm = (JDBCStoreManager)myPersistenceManager
          .getStoreManager ();
     SQLExecutionListener listener = new AbstractSQLExecutionListener ()
          public void beforeCommit (SQLExecutionEvent event, Connection c)
               c.createStatement ().executeUpdate ("DO SOME SQL STUFF BEFORE COMMIT");
     sm.addSQLExecutionListener (listener);
See the API at:
http://www.solarmetric.com/docs/latest/docs/javadoc/com/solarmetric/kodo/impl/jdbc/SQLExecutionListener.html
In article <[email protected]>, Eivind Skildheim wrote:
I thought that getting the SQL connection from PersisientManager would allow
me to do
JDBC stuff on the same connection and in the same transaction. But I cannot
get SQL updates
to 'persist' without calling commit on the transaction.
Is this a bug, user error, or as designed. If any oh the last two, how
can I do db updates through JDBC and have them being tied to the same
transaction as the PM's transaction (and commit when it commits)?
Below is a test program where I expected the number of rows returned to be
1, but
it returns zero.
Thanks,
Eivind Skildheim
Motive Communications, Inc
import java.io.File;
import java.io.FileInputStream;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager;
import com.solarmetric.kodo.runtime.PersistenceManagerImpl;
public class KodoTest
public static void main(String[] args)
try
Properties props = new Properties();
props.load(new FileInputStream(args[0]));
PersistenceManagerFactory pmf =
JDOHelper.getPersistenceManagerFactory (props);
PersistenceManager pm = pmf.getPersistenceManager();
pm.currentTransaction().begin();
JDBCStoreManager sm = getStoreManager(pm);
Connection conn = sm.getConnection();
Statement stmt = conn.createStatement();
stmt.executeUpdate("create table foo(bar number not null)");
stmt.executeUpdate("insert into foo(bar) values(1)");
sm.releaseConnection(conn);
conn = sm.getConnection();
stmt = conn.createStatement();
ResultSet row = stmt.executeQuery("select count(*) from foo");
row.next();
getLogger().info("Number of rows = " + row.getInt(1));
sm.releaseConnection(conn);
System.exit(0);
catch(Throwable e)
getLogger().error("", e);
System.exit(1);
private static JDBCStoreManager getStoreManager(PersistenceManager pm)
return (JDBCStoreManager)
((PersistenceManagerImpl)pm).getStoreManager();
private static Log getLogger()
return LogFactory.getLog(KodoTest.class);
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Similar Messages

  • EJB calling Spring Bean with non XA Datasources causing Rollback Exception

    We have an EJB CMT with Required calling a spring bean (@Transactional Propagation.NOT_SUPPORTED). This is causing an Rollback Exception saying 2 phase commit must be enabled. The EJB has to write to datasource 1, but the Spring Bean is ready only on Data Source 2. The Data Sources are set to use Non XA Driver with Support Global Transaction enabled for One phase commit. Any help is appreciated.

    We have an EJB CMT with Required calling a spring bean (@Transactional Propagation.NOT_SUPPORTED). This is causing an Rollback Exception saying 2 phase commit must be enabled. The EJB has to write to datasource 1, but the Spring Bean is ready only on Data Source 2. The Data Sources are set to use Non XA Driver with Support Global Transaction enabled for One phase commit. Any help is appreciated.

  • Error 1950 re install of Elem11 caused rollback

    Sorry, I gave an incorrect Error #. It should be 1950. Is reply from Jeff still valid?

    Hi Xscouse,
    You might want to refer the KB : http://helpx.adobe.com/photoshop-elements/kb/troubleshoot-installation-photoshop-elements- premiere.html#An error during setup causes the installer to roll back (Windows-only)
    http://helpx.adobe.com/photoshop-elements/kb/install-rollback-photoshop-elements-windows.h tml

  • Photoshop Elements 12 installation error on windows causing rollback-help needed please

    I am installing Photoshop Elements 12 on my windows laptop. When almost done an error occurs and it starts rollback and the installation fails. I consulted the troubleshooting guide which suggests to go to C://Program Files(x86)/Common Files/Adobe/OOBE/PDApp and delete the files PDAppFlex.swf and PDAppFlex-app.xml .I have managed to go to Program Filesx86, Common Files, Adobe, but then the folder OOBE is absent. Within the Adobe folder I have AAMUpdaterinventry, Acrobat, Acrobat PCD, Help, PCF, SL Cache and Updater6. The files suggested to delete before retrying installation are not present in any of these folders.
    Has anybody any ideas on what I should do in order to complete my installation.
    Thanks very much,
    Tim

    Without proper detailed system information nobody can know what is going on. Also try to find the pertinent info from the install logs.
    Mylenium

  • Tpforward tpabort causing rollback to oracle database ?

    Hello all,
    we have issue with xa transactions.
    We obtained tpabort / rollback as you can see from the trace.
    We are trying to send messges from queue using tpforward to databse using oci - through "ods" adapter.
    This issue is obtained sometimes, after the restart of adapter to the database.
    I do not know, if the error is because of DB rollback or because of tpabort as you can see from trace:
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpabort(0x0)
    interesting is also xa_end = 104 after tpabort.
    The queue is mostly 99% working well, what can be the origin of the problem please? Why is tmqforward behaving like this?
    Queue contains just 64 messages which can't be commited. They were sent to db adapter (ods) and to Oracle DB and we obtained answer message from DB, but the rollback/tpabort puts the message back to the queue and this is repeating indefinitely...
    tuxedo 9.1 rp 92, parsic 32b on itanium (emul)
    ubb:
    Q_ODS3 LMID=TuxC     GRPNO=313 TMSCOUNT=5     TMSNAME=TMS_QM          OPENINFO="TUXEDO/QM:/home/tux-st1/queues/QUEMSG_ODS:QSPACEMSG_ODS"
    DEFAULT:     MIN=1     MAX=8 SEQUENCE=133
    TMQUEUE                    SRVID=10040     SRVGRP=Q_ODS3     CLOPT="-o logs/stdout -e logs/stderr -s QSPACEMSG_ODS:TMQUEUE -s QSPACEMSG_ODS3:TMQUEUE -- "
    TMQFORWARD     MIN=3     MAX=20     SRVID=10050     SRVGRP=Q_ODS3     CLOPT="-o logs/stdout -e logs/stderr -- -i 2 -q DISPATCHER_ODS"
    TMQFORWARD     MIN=2     MAX=10     SRVID=10070     SRVGRP=Q_ODS3     CLOPT="-o logs/stdout -e logs/stderr -- -i 10 -q CONFIRMATION"
    script for creating queue:
    qcreateMSG.sh 44 _ODS:
    #!/bin/sh
    # Version: $Id: qcreateMSG.sh 1398 2010-04-15 08:35:37Z vkoutny $
    IPCKEY=$1`id -u`
    echo IPCKEY = $IPCKEY
    export QMCONFIG=$APPDIR/queues/QUEMSG$2
    qmadmin $QMCONFIG << END1
    echo
    qspds -f -y QSPACEMSG$2
    q
    END1
    rm $QMCONFIG
    qmadmin $QMCONFIG << END
    echo
    crdl $QMCONFIG 0 60100
    qspacecreate
    QSPACEMSG$2
    $IPCKEY
    60000
    10
    400
    400
    30000
    ERRORQ
    y
    16
    qopen QSPACEMSG$2
    qcreate
    DISPATCHER$2
    priority,time,fifo
    msgid
    0
    0
    33%
    5%
    sh $APPDIR/scripts/qfull.sh 24 QSPACEMSG$2 $QMCONFIG DISPATCHER$2
    qcreate
    CONFIRMATION
    priority,time,fifo
    msgid
    0
    0
    33%
    5%
    sh $APPDIR/scripts/qfull.sh 24 QSPACEMSG$2 $QMCONFIG CONFIRMATION
    qcreate
    ERRORQ
    priority,time,fifo
    msgid
    5
    10
    33%
    5%
    sh $APPDIR/scripts/qfull.sh 24 QSPACEMSG$2 $QMCONFIG ERRORQ
    q
    END
    thank you for any advice,
    Jan
    tuxedo trace:
    tux-st1@tuxcst:/home/tux-st1/logs$ grep "gtrid x20002 x4f6201d3 x10ab57e" ULOG.033012
    120446.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_start(0x40024d5c, 0, 0x0)
    120446.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_start = 0
    120446.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpbegin = 1
    120446.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpsprio(50, 0x40)
    120446.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpsprio = 1
    120446.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_end(0x40024d5c, 0, 0x2000000)
    120446.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_end = 0
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpservice({"DISPATCHER_ODS", 0x10, 0x40104b70, 1828, 0, -2147483648, {0, -2, -1}})
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpgprio()
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpgprio = 50
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpalloc("STRING", "", 506)
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpalloc = 0x40093b40
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpalloc("STRING", "", 506)
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpalloc = 0x40093fb8
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpsprio(50, 0x40)
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpsprio = 1
    120446.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpcall("ENTRYODS", 0x40093b40, 506, 0x7f7f1208, 0x7f7f1084, 0x3)
    120446.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_start(0x400356f4, 0, 0x0)
    120446.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_start = 0
    120446.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:tr: dye
    120446.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpservice({"ENTRYODS", 0x10, 0x4027ad70, 507, 0, -2147483648, {0, -2, -1}})
    120446.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpgetlev()
    120446.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpgetlev = 1
    120447.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpalloc("CARRAY", "", 236)
    120447.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpalloc = 0x4006e348
    120447.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpreturn(2, 0, 0x4006e348, 235, 0x0)
    120447.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_end(0x400356f4, 0, 0x4000000)
    120447.tuxc!ods.29438.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_end = 0
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpcall = 0
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpacall("FILEWRITER", 0x40104b70, 0, 0xe)
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpacall = 0 [CLIENTID {0, -2, -1}]
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpfree(0x40104b70)
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpfree
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpfree(0x40093b40)
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpfree
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpfree(0x400f69c8)
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: } tpfree
    120447.tuxc!dispatcher.9870.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:at: { tpreturn(2, 0, 0x00000000, 0, 0x0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_start(0x40024d5c, 0, 0x8000000)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_start = 0
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpabort(0x0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_end(0x40024d5c, 0, 0x20000000)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_end = 104
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpalloc("rpcrqst", "", 0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpalloc = 0x4008d5e0
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpsprio(75, 0x40)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpsprio = 1
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpfree(0x4008d5e0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpfree
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpalloc("rpcrqst", "", 0)
    120447.tuxc!TMS_QM.28617.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:tr: dye
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpalloc = 0x4008d5e0
    120447.tuxc!TMS_QM.28617.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpservice({"..TMS", 0x14, 0x00000000, 0, 0, -2147483648, {0, -2, -1}})
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpsprio(75, 0x40)
    120447.tuxc!TMS_QM.28617.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_rollback(0x4002539c, 0, 0x0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpsprio = 1
    120447.tuxc!TMS_QM.28617.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_rollback = -4
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpfree(0x4008d5e0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpfree
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpalloc("rpcrqst", "", 0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpalloc = 0x4008d5e0
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpsprio(75, 0x40)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpsprio = 1
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpfree(0x4008d5e0)
    120447.tuxc!TMQFORWARD.28638.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: } tpfree
    120447.tuxc!TMS_ORACLE10g.29337.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:tr: dye
    120447.tuxc!TMS_ORACLE10g.29337.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:ia: { tpservice({"..TMS", 0x14, 0x00000000, 0, 0, -2147483648, {0, -2, -1}})
    120447.tuxc!TMS_ORACLE10g.29337.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: { xa_rollback(0x40025734, 0, 0x0)
    120447.tuxc!TMS_ORACLE10g.29337.1.0: gtrid x20002 x4f6201d3 x10ab57e: TRACE:xa: } xa_rollback = 0
    XA-log-trace:
    120446.29438.0:
    xaostart: xid=0x28-7475786300000000000000000000000000000000000000000000000000000000000ebf224f6201d3010ab57e-0000013900000081, rmid=0, flags=0x0
    120446.29438.0:
    OCITransStart: Attempting
    120446.29438.0:
    OCITransStart: Succeeded
    120446.29438.0:
    xaostart: return XA_OK
    120447.29438.0:
    xaoend: xid=0x28-7475786300000000000000000000000000000000000000000000000000000000000ebf224f6201d3010ab57e-0000013900000081, rmid=0, flags=0x4000000
    120447.29438.0:
    OCITransDetach: Attempting
    120447.29438.0:
    OCITransDetach: Succeeded
    120447.29438.0:
    xaoend: return 0
    120447.29337.0:
    xaorollback: xid=0x28-7475786300000000000000000000000000000000000000000000000000000000000ebf224f6201d3010ab57e-0000013900000081, rmid=0, flags=0x0
    120447.29337.0:
    OCITransRollback: Attempting
    120447.29337.0:
    OCITransRollback: Succeeded
    120447.29337.0:
    xaorollback: rtn 0

    Hi Todd,
    first of all - thank you for your answer.
    I have found the reason.
    I just defined non existing replyqueue in tpenqueue's TPQCTL structure.
         stCtrl.flags |= TPQREPLYQ;
         strcpy(stCtrl.replyqueue, pcReplyQueueName);
    This behaviour was very hidden for me, because I did not receive any error message to logs.
    If the reply queue which I defined in structure not exists in quespace, then the abort is called internally...
    Now resolved.
    Thank you,
    Jan

  • ORA-01555: snapshot too old: rollback segment number 3 with name "RB02

    It just happen while processing ....

    01555, 00000, "snapshot too old: rollback segment number %s with name \"%s\" too small"
    // *Cause: rollback records needed by a reader for consistent read are
    // overwritten by other writers
    // *Action: If in Automatic Undo Management mode, increase undo_retention
    // setting. Otherwise, use larger rollback segments

  • Error while executing a procedure in pl/sql

    Hi,
    iam execvuting a procedure in pl/sql and i get the following error,
    proc Running: Wed Sep 7 06:13:20 IST 2005
    Table truncated.
    BEGIN <procedure_name> ; END;
    ERROR at line 1:
    ORA-01555: snapshot too old: rollback segment number 75 with name "RBS74" too
    small
    ORA-06512: at "<procedure_name>", line 104
    ORA-06512: at line 1
    could anyone explain what has gone wrong in this case???

    According to the documentation:
    ORA-01555: snapshot too old: rollback segment number string with name "string" too small
    Cause: Rollback records needed by a reader for consistent read are overwritten by other writers.
    Action: If in Automatic Undo Management mode, increase the setting of UNDO_RETENTION. Otherwise, use larger rollback segments.
    Error: ORA-01555: snapshot too old (rollback segment too small)
    Cause: This error can be caused by one of the problems, as described below.
    Action: The options to resolve this Oracle error are:
    This error can be the result of there being insufficient rollback segments.
    A query may not be able to create the snapshot because the rollback data is not available. This can happen when there are many transactions that are modifying data, and performing commits and rollbacks. Rollback data is overwritten when the rollback segments are too small for the size and number of changes that are being performed.
    To correct this problem, make more larger rollback segments available. Your rollback data for completed transactions will be kept longer.
    This error can be the result of programs not closing cursors after repeated FETCH and UPDATE statements.
    To correct this problem, make sure that you are closing cursors when you no longer require them.
    This error can occur if a FETCH is executed after a COMMIT is issued.
    The number of rollback records created since the last CLOSE of your cursor will fill the rollback segments and you will begin overwriting earlier records.

  • Error 03113 while executing java procedure with pl.sql

    Hi All,
    I am using oracle 10g on linux server. Client machine is on xp. I hava a java procedure which executes the sqlldr on server. Earlier it was working fine, but after reinstalling the oracle 10g on server. It started giving "end of Communication channel error". I am not aware that what paramete has to set. Can some body put light on this error.
    Bye
    Sachin

    According to the documentation:
    ORA-01555: snapshot too old: rollback segment number string with name "string" too small
    Cause: Rollback records needed by a reader for consistent read are overwritten by other writers.
    Action: If in Automatic Undo Management mode, increase the setting of UNDO_RETENTION. Otherwise, use larger rollback segments.
    Error: ORA-01555: snapshot too old (rollback segment too small)
    Cause: This error can be caused by one of the problems, as described below.
    Action: The options to resolve this Oracle error are:
    This error can be the result of there being insufficient rollback segments.
    A query may not be able to create the snapshot because the rollback data is not available. This can happen when there are many transactions that are modifying data, and performing commits and rollbacks. Rollback data is overwritten when the rollback segments are too small for the size and number of changes that are being performed.
    To correct this problem, make more larger rollback segments available. Your rollback data for completed transactions will be kept longer.
    This error can be the result of programs not closing cursors after repeated FETCH and UPDATE statements.
    To correct this problem, make sure that you are closing cursors when you no longer require them.
    This error can occur if a FETCH is executed after a COMMIT is issued.
    The number of rollback records created since the last CLOSE of your cursor will fill the rollback segments and you will begin overwriting earlier records.

  • What is luw (logical unit of work)

    pls tell me what is luw (logical unit of work)
    what r the types of luw .
    2 what ispurpose of code inspector and extended program check
    pls expalin the diffrence b/w those two
    3what are the candidate keys in db tables
    4 what is the difference b/w  occurs 1 and occurs 2 clauses
    data : begin of itab occurs 0 .
    data : itab type standard table of structure type initial size 1 with header line
    pls tell diffrence between theese two statements
    5can u pls tell what is the client in sap
    pls tell answers to questions
    pls dont give any websites addresses to see answers
    6 what is the transaction from database point of view
    7 what is the variant in alv reports
    how do we use reuse_alv_grid_variant_get fun module in alvs

    hi,
      this gives complete idea
      SAP LUW
    Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
    To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.
    Two techniques are available for bundling the change statements in a database LUW:
    Bundling via function modules (update)
    Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.
    Bundling via function modules (transactional RFC)
    Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).
    Bundling via subprograms
    Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.
    Statements for SAP LUWs
    A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.
    Note
    A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.
    COMMIT WORK
    Variants:
    1. COMMIT WORK [AND WAIT].
    2. COMMIT CONNECTION con.
    Effect
    Terminates an SAP LUW and stores the changes.
    Variant 1
    COMMIT WORK [AND WAIT].
    Effect
    The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
    It executes all subroutines registered using PERFORM ON COMMIT.
    It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.
    It initiates the processing of all registered update function modules in the update work process.
    This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
    If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
    In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.
    It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.
    It triggers a database commit that also terminates the current database LUW.
    The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.
    If the statement COMMIT WORK is executed by calling special programs, be aware of the following:
    In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.
    In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.
    You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.
    System fields
    sy-subrc Meaning
    0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.
    4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.
    The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.
    Note
    The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.
    Variant 2
    COMMIT CONNECTION con.
    Note
    This statement is for internal use only.
    It cannot be used in application programs.
    Effect
    The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.
    On the specified secondary database connection, the database commit:
    Closes all open database cursors (OPEN CURSOR)
    Releases all database locks
    Note
    Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.
    Exceptions
    Non-Catchable Exceptions
    Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.
    Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT
    Cause: COMMIT WORK is not allowed in the update.
    Runtime Error: COMMIT_IN_POSTING
    ROLLBACK WORK
    Variants:
    1. ROLLBACK WORK.
    2. ROLLBACK CONNECTION con.
    Effect
    Terminates a SAP-LUW without storing the changes.
    Variant 1
    ROLLBACK WORK.
    Effect
    The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:
    Executes all subprograms registered with PERFORM ON ROLLBACK.
    Deletes all subprograms registered with PERFORM ON COMMIT.
    Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.
    Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.
    Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.
    Triggers a database rollback, which also ends the current database-LUW.
    After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.
    Variant 2
    ROLLBACK CONNECTION con.
    Note
    This statement is for internal use only.
    It cannot be used in application programs.
    Effect
    The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.
    Notes
    As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.
    After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.
    ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.
    The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.
    Exceptions
    Non-Catchable Exceptions
    Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.
    Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT
    Cause: ROLLBACK WORK is not allowed within an update.
    Runtime Error: ROLLBACK_IN_POSTING
    SET UPDATE TASK LOCAL
    Syntax
    SET UPDATE TASK LOCAL.
    Effect
    This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.
    At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.
    System fields
    sy-subrc Meaning
    0 The local update function is activated.
    1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.
    Notes
    The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.
    The occurrence of a database rollback during the local update affects all previous change requests.

  • Issues with WSDL file loading in BPEL process Composite

    hi',
    I am facing lot of issues in 11G
    I am using:-->"Jdeveloper Studio Edition Version 11.1.1.2.0"
    When I am trying to open a already working composite from a different machine in my machine, it start giving error
    it is unable to build "Unable to load WSDL file", I have all the webservices in different machine OSB and my machine
    is targeting that machine OSB with IP address, In my BPEL process I am using localhost, I am able to see all the methods
    in composite and dosent shows any error, but when I try to compile it it gives unable to load WSDL file.
    please advice,
    thanks
    Yatan

    I suppose, any unhandled exception in the one-way BPEL process could have caused rollback of the instance and hence the instance might not be seen. Add fault handlers-catch/catch-all blocks in the one-way BPEL process if not done already, and test.

  • MV refreshing

    When I refresh a materialized view, I'm getting the following error message
    ERROR at line 1:
    ORA-12008: error in materialized view refresh path
    ORA-01555: snapshot too old: rollback segment number 7 with name "_SYSSMU7$"
    too small
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 1883
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2089
    ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2058
    ORA-06512: at line 1
    Could anybody let me know what is creating this error.
    Thanks.

    Your rollback/undo segment is too small.
    C:\sql>oerr ora 01555
    01555, 00000, "snapshot too old: rollback segment number %s with name \"%s\" too small"
    *Cause: rollback records needed by a reader for consistent read are
    overwritten by other writers
    *Action: If in Automatic Undo Management mode, increase undo_retention
    setting. Otherwise, use larger rollback segments
    C:\sql>

  • State of Transaction in High Safety mode (Synchronous mode)

    Hello Team,
    I have configured Database Mirroring with High Safety mode ( Synchronous Mode). I have started a long transaction (transaction A) which is expected to complete in 10 minutes. However, principal server shuts down due to hardware issue.
    What will happen to the transaction A.
    Also, what will be state of transaction if i have configured Mirroring with High Performance Mode (Asynchronous Mode).
    Chetan

    1. Transaction is being executed on Principal server and mirroring fails
    In this scenario SQL Server would not be able to commit its transaction because it wont be able to send log records to mirror and hence would not be able to get acknowledgement about commit on mirror. Transaction log will grow till it occupies whole space
    and then application might stop responding as database would not able to log transactions. DB might also go in unresponsive state
    2. Transaction is completed execution on principal server, it is being executing on mirrored server and mirroring fails
    Transaction replay happens almost at same time (with little delay) . The mirror receives and writes the log buffer to disk and records the mirroring_failover_lsn and notifies the principal that the log block has been hardened. If commit has been acknowledged
    on mirror and principal both before failover, then after when mirror will come online it will replay transaction. Anything before that would cause rollback on mirror.
    3. Transaction is completed execution on principal server & mirroring server. Before principal server receives confirmation from mirrored server about execution completion, mirroring fails.
    Actually this question is bit confusing and in some way incorrect I would like you to read
    Table 9: A Safety FULL (Synchronous transfer) example sequence of events.
    in below link
    http://technet.microsoft.com/en-us/library/cc917680.aspx
    The possible answer is rollback on mirror.
    Edit: In case of any conflict LSN on both principal and mirror is used to resolve conflict. Remember mirroring does not works in two phase commit like distributed transaction failures to commit on the mirror will not cause a transaction rollback on the principal.
    Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it
    My Technet Wiki Article
    MVP

  • RE:logical unit of work

    Hi guys,
    What do u mean by logical unit of work...Can anyone explain me with an example.
    Regards,
    Alex.

    hi,
    this gives complete idea
    SAP LUW
    Since, as a rule, an application program is processed by several work processes in succession, and every change of the work process is linked with an implicit database commit , an application program is not automatically linked with a single database LUW. This applies in particular to dialog-oriented applications, in which one database LUW is assigned to one dialog step.
    To ensure the data consistency of application programs that are executed across different work processes, the application statements are not directly executed in an SAP LUW, rather, are first registered and then executed by a single work process, that is, in a single database LUW.
    Two techniques are available for bundling the change statements in a database LUW:
    Bundling via function modules (update)
    Through the statement CALL FUNCTION...IN UPDATE TASK, an update function module is registered for subsequent execution in an update work process.
    Bundling via function modules (transactional RFC)
    Through the statement CALL FUNCTION... IN BACKGROUND TASK DESTINATION, a remote- compatible function module is registered for subsequent asynchronous execution via the RFC interface (transactional RFC ).
    Bundling via subprograms
    Through the statement PERFORM ... ON COMMIT, a subprogram is registered for subsequent execution in a different work process.
    Statements for SAP LUWs
    A SAP LUW is controlled via the Open SQL statements COMMIT WORK, ROLLBACK WORK and SET UPDATE TASK LOCAL.
    Note
    A function module can be classified either as an update function module or remote-compatible, but not both at the same time. The update helps realize SAP LUWs within an SAP System, while the transactional RFC creates LUWs in distributed systems.
    COMMIT WORK
    Variants:
    1. COMMIT WORK [AND WAIT].
    2. COMMIT CONNECTION con.
    Effect
    Terminates an SAP LUW and stores the changes.
    Variant 1
    COMMIT WORK [AND WAIT].
    Effect
    The statement COMMIT WORK completes the current SAP LUW and opens a new one, storing all change requests for the currenta SAP LUW in the process. In this case, COMMIT WORK performs the following actions:
    It executes all subroutines registered using PERFORM ON COMMIT.
    It triggers an internal event in Object Services that ensures the registration of changes in persistent objects as the last update function module, as well as the subsequent initialization of persistent object attributes.
    It initiates the processing of all registered update function modules in the update work process.
    This executes all high-priority update function modules registered using CALL FUNCTION ... IN UPDATE TASK in the order of their registration and in a common database LUW. If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating). If you specify the addition AND WAIT, however, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
    If all high-priority update function modules are completed successfully, the statement executes the low-priority update function modules together in a common database LUW.
    In parallel, it also executes the individual function modules registered using CALL FUNCTION ... IN BACKGROUND TASK DESTINATION in a separate database LUW for each destination.
    It handles all SAP locks set in the current program according to the value of the formal parameter _SCOPE of the corresponding lock function modules.
    It triggers a database commit that also terminates the current database LUW.
    The completion of statement COMMIT WORK triggers the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE, where the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>COMMIT_WORK.
    If the statement COMMIT WORK is executed by calling special programs, be aware of the following:
    In a program executed using batch input, or if you have called the program using the USING addition of the statement CALL TRANSACTION, COMMIT WORK terminates the batch input processing when using the corresponding settings.
    In a program called using CALL DIALOG, COMMIT WORK initiates the processing of subroutines or updated function modules registered using PERFORM ... ON COMMIT and CALL FUNCTION ... IN UPDATE TASK. Therefore, it does not complete the current SAP LUW. The SAP LUW cannot be completed until you execute the COMMIT WORK statement in the calling program.
    You cannot execute the COMMIT WORK statement during the updating procedure or during the execution of subroutines registered using PERFORM ... ON {COMMIT|ROLLBACK}.
    System fields
    sy-subrc Meaning
    0 You have specified the AND WAIT addition, and the updating of the update function modules was successful.
    4 You have specified the AND WAIT addition, and the updating of the update function modules was not successful.
    The COMMIT WORK statement always sets sy-subrc to 0 if the AND WAIT addition is not specified.
    Note
    The COMMIT WORK statement closes all database cursors . Open SQL statements that access a database cursor later ( SELECT loop and FETCH) raise an exception that cannot be handled.
    Variant 2
    COMMIT CONNECTION con.
    Note
    This statement is for internal use only.
    It cannot be used in application programs.
    Effect
    The COMMIT command is not executed on the standard database, but only on the secondary database connection specified by con. con is the name of the database connection as it was specified in the table DBCON in the column CON_NAME. The database connection con can also be specified dynamically in the form (source_text) - the source_text field contains the name of the database connection. The source_text field must be of the type C or STRING.
    On the specified secondary database connection, the database commit:
    Closes all open database cursors (OPEN CURSOR)
    Releases all database locks
    Note
    Note that the COMMIT CONNECTION DEFAULT statement unlike COMMIT WORK executes a pure database commit on the DEFAULT connection.
    Exceptions
    Non-Catchable Exceptions
    Cause: COMMIT WORK is not possible in a FORM that was called using PERFORM ... ON COMMIT.
    Runtime Error: COMMIT_IN_PERFORM_ON_COMMIT
    Cause: COMMIT WORK is not allowed in the update.
    Runtime Error: COMMIT_IN_POSTING
    ROLLBACK WORK
    Variants:
    1. ROLLBACK WORK.
    2. ROLLBACK CONNECTION con.
    Effect
    Terminates a SAP-LUW without storing the changes.
    Variant 1
    ROLLBACK WORK.
    Effect
    The statement ROLLBACK WORK closes the current SAP-LUW and opens a new one. In doing so, all change requests of the current SAP-LUW are canceled. To do this, ROLLBACK WORK carries out the following actions:
    Executes all subprograms registered with PERFORM ON ROLLBACK.
    Deletes all subprograms registered with PERFORM ON COMMIT.
    Raises an internal exception in the Object Services that makes sure that the attributes of persistent objects are initialised.
    Deletes all update function modules registered with CALL FUNCTION ...IN UPDATE TASK from the VBLOG and deletes all transactional remote Function Calls registered with CALL FUNCTION ... IN BACKGROUND TASK from ARFCSSTATE and from ARFCSDATA.
    Removal of all SAP locks set in the current program in which the formal parameter _SCOPE of the lock function module was set to the value 2.
    Triggers a database rollback, which also ends the current database-LUW.
    After completion of the statement COMMIT WORK, the event TRANSACTION_FINISHED of the system class CL_SYSTEM_TRANSACTION_STATE is raised, in which the parameter KIND has the value of the constant CL_SYSTEM_TRANSACTION_STATE=>ROLLBACK_WORK.
    Variant 2
    ROLLBACK CONNECTION con.
    Note
    This statement is for internal use only.
    It cannot be used in application programs.
    Effect
    The ROLLBACK-statement is not executed on the standard database but only on the secondary database connection, specified through con. con is the name of the database connection as it was specified in table DBCON in column CON_NAME. The database connection con can also be specified dynamically in the form (source_text), in which the field source_text contains the name of the database connection. The field source_text must be of the type C or STRING.
    Notes
    As all opened database cursors on the respective database connections are closed at ROLLBACK, the attempt to continue a SELECT-loop after a ROLLBACK, leads to a runtime error. Due to the same reason, a FETCH after a ROLLBACK to the then closed cursor, leads to a runtime error. You have to make sure that cursors that are still open, are no longer used after ROLLBACK.
    After execution of the statement ROLLBACK, SY-SUBRC is always equal to 0. It is not necessary to check if SY-SUBRC is unequal to 0 after ROLLBACK.
    ROLLBACK must not be used during update (CALL FUNCTION ... IN UPDATE TASK) or during the execution of FORMs, which were registered with PERFORM ... ON COMMIT resp. PERFORM ...ON ROLLBACK.
    The statement ROLLBACK WORK is implicitly executed if a message of the type A is treated with the addition ERROR_MESSAGE when calling a function module with CALL FUNCTION.
    Exceptions
    Non-Catchable Exceptions
    Cause: ROLLBACK WORK is not allowed within a FORM that is called with PERFORM ... ON COMMIT or PERFORM ... ON ROLLBACK.
    Runtime Error: ROLLBACK_IN_PERFORM_ON_COMMIT
    Cause: ROLLBACK WORK is not allowed within an update.
    Runtime Error: ROLLBACK_IN_POSTING
    SET UPDATE TASK LOCAL
    Syntax
    SET UPDATE TASK LOCAL.
    Effect
    This statement specifies that the high-priority update function modules - registered during the current SAP LUW using CALL FUNCTION ... IN UPDATE TASK - are registered in the ABAP memory instead of the VBLOG database table. In addition, it specifies that the current work process and not the update work process run these modules during the current database LUW, when the COMMIT WORK statement is executed. This statement has no effect on low-priority update function modules.
    At the beginning of every SAP LUW, the local update function is deactivated. If you wish to use it, you must reactivate it again before the first update function module is registered.
    System fields
    sy-subrc Meaning
    0 The local update function is activated.
    1 The local update function has not been activated, because the program has already registered at least one update function module for the normal updating procedure in the current SAP-LUW.
    Notes
    The local update function performs a synchronous update according to the COMMIT WORK statement, independent of the addition AND WAIT.
    The occurrence of a database rollback during the local update affects all previous change requests.
    Regards
    vasu

  • Short dump errors desc--how to resolve

    I would like to know the short dump errors meaning and how to resolve it. i have the following errors
    1. TSV_TNEW_PAGE_ALLOC_FAILE----
    for this the description for ERROR ANALYSIS is : The internal table "IT_24" could not  be enlarged further. To allow error handling, the table has to be deleted before this log was created.HOW TO CORRECT THE ERROR is : the amount of storage space was  (in bytes) filled at termination time was:
    Roll area..........1708928
    Extended memory (EM).........440057520
    Assigned memory (HEAP).......465813648
    short area.........." "
    Paging area.....33857536
    Maximum address space....." "
    2. DBIF_DSQL2_SQL_ERROR----
    HOW TO CORRECT THE ERROR is:
    Database error text......."ORA-01555: snapshot too old: rollback segment number 2 with name "PRS_0" too small"
    Database error code - 1555
    Triggering SQL statement......."FETCH NEXT"
    Internal call code................"[DBDS / NEW DSQL]"               
    Please check the entries in the system log (Trasaction SM21)
    3. TSV_LIN_ALLOC_FAILED----
    this error analysis which also gives HOW TO CORRECT THE ERROR is almost the same like the first error description which i have written like memory space and so on
    i would appreciate if u could clarify these errors and how to resolve it. Thanks in advance.

    Hi,
    TSV_TNEW_* error are the memory problems in BI, you need to wait untill the system load is reduced...check the TA: SM37 and then repeat the failed steps, it will be successful.
    DBIF_* are database releated errors....oracle backend error, u need to find out where the error has occured in the SQL statement and fix the error.
    Usually these errors will the locks.
    Oracle 8i error message says:
    <u><b>ORA-01555</b></u>
    snapshot too old: rollback segment number string with name "string"
    too small
    Cause: Rollback records needed by a reader for consistent read are overwritten
    by other writers.
    Action: Use larger rollback segments.
    Regards,
    Vijay
    Message was edited by:
            Vijaya Kumar Malyavantham

  • Re: Constant Message Redelivery Problem

    You can get redelivery for other reasons as well. Redelivery occurs if the message is
              participating in a transaction, and the transaction fails for any reason.
              For example, if the MDB in turn calls an EJB which in
              turn calls JDBC then the tx becomes two-phase. If the JDBC call fails then the tx
              will roll back. Or if the tx times-out: the default tx timeout is 30 seconds, so if
              the MDB takes longer than 30 seconds then the tx will roll-back and message the will
              get redelivered.
              Even if the tx succeeds, in some cases you may have error states that re-enqueue the
              received message but let the transaction commit (WLI, BEA's integration product, can do
              this).
              This looks like the redelivery of a failed message, but is actually the delivery of a new
              version.
              Duplicates occur if a Queue MDB's descriptor actually points at a topic destination.
              Check for this one by comparing the JNDI name in config.xml against the
              descriptor destination type field...
              Tom
              sunshine wrote:
              > I encountered the same problem of repeat message delivery. In our situation, we are
              > using JMS JDBC Store and when the database goes down and comes back up, the MDB starts
              > processing messages but the messages keep recycling in the JMS Store.
              >
              > The MDB code tried catching all possible exceptions like RuntimeException and Exception.
              > None of these exceptions are logged. When we re-start the WL managed servers, those
              > messages in the JMS Store were flushed off.
              >
              > Any idea what caused the repeat message redelivery?? Thanks.
              >
              > Tom Barnes <[email protected]> wrote:
              > >Your MDB may be throwing a RuntimeException, which forces message
              > >redelivery. Put a try/catch/Throwable in the outermost scope of your
              > >onMessage() code to see if this is case.
              > >
              > >Note that in 6.1 and up you can configure redelivery delays, max redelivery
              > >counts and error destinations to alleviate this problem...
              > >
              > >Tom
              > >
              > >Toad wrote:
              > >
              > >> I have a message-driven bean listening on a message queue and everything
              > >> appears to work the first time the message is sent. The message is processed
              > >> and the OnMessage method returns without incident. There are no errors
              > >and
              > >> no exceptions are thrown by the JMS client or in the MDB itself. PROBLEM:
              > >> Message continually redelivered pegging the CPU at 100%. Inspection of
              > >the
              > >> JMSSTORE and JMSSTATE reveals messages still queued. Any ideas?
              > >
              

    And make sure that your MDB is not throwing Errors or RuntimeExceptions,
              as these don't necessarily get logged, but they cause rollbacks.
              Put a "try {} catch (RuntimeException re)
              { log; throw re; } catch (Error er) { log; throw er; }"
              around all the code within the MDB's "onMessage()" callback
              to see if this is happening.
              Manikyala Peddi wrote:
              > Hi,
              >
              > I have a MDB which is calling an EJB. The redelivery override period was set at 60 sec.
              >
              > Before completing the first message the same message is redelivered.The processing time in onMessage in MDB takes more than the Redelivery Override Period. Is there a way to prevent the delivery of the duplicate message before completing the first message.Iam using Weblogic 7.1
              >
              > Thanks
              >
              > Manikyala
              

Maybe you are looking for

  • Unable to view actuals in Project Management's workplan (self-service page)

    Hi, I followed all steps you suggested, in details: first of all I not enable workplan versioning like PJT R12 manual says at page 2-47. 1-Create a requisition for the project-task combination, then autocreate a purchase order and finally a receipt t

  • Message error in cocoa

    compiling a cocoa-project I have found this error message: Command /Developer/usr/bin/gcc-4.2 failed with exit code 1 can someone clear to me what kind of error is this?

  • HP photosmart p 1000

    My photosmart p 1000 has worked like a trooper for years. Recently, the color ink stopped working. B&W works properly but it simply wont print in color. COlor cartridge shows 90% full, its inserted properly (as evidenced by the fact that the toolbox

  • Apex Homepage is not showing up

    Hi, I am new to APEX and i would really like to learn about it. I have the following environment OS : Linux SUSE9 Database : Oracle Database 10.2.0.3 OracleHTTP Server 10.2.0.1 (installed from Oracle 10g Companion CD) APEX 3.0.1 I have Oracle HTTP Se

  • [Oracle Linux 6.3] Impossible to configure ASMlib

    Hi, [root@ahmed-ol6 sf_Softs]# uname -a Linux ahmed-ol6 2.6.32-279.19.1.el6.i686 #1 SMP Tue Dec 18 15:04:25 PST 2012 i686 i686 i386 GNU/Linux [root@ahmed-ol6 oracle]# cat /etc/oracle-release Oracle Linux Server release 6.3 [root@ahmed-ol6 sf_Softs]#