Topic: XA transactions and JCA 1.5

Hi,
I am new in the area of connectivity and integration and I have a question regarding supporting XA transactions.
I have a EIS that supports XA transactions. Now, I want to integrate this EIS into a J2EE Application Server. Currently, there is no Resource Adapter (RA) implemented for this EIS.
Is it mandatory to supply a RA for this EIS in order to enable this system to participate in XA transactions? Can a EIS be connected to an Application Server without using JCA, and make XA transactions work?
Thanks,
--------------------

If your EIS has data in a database you could use JDBC to access that data, or if your EIS uses a messaging system you could use JMS. These are the easier options.
Otherwise you are going to have to use a JCA adapter to get it to participate in an XA transaction. Its not the easiest thing in the world to do - buy one if you can rather than write one. Otherwise there are a couple of books out there with tutorials, such as the SAMS book Java Connector Architecture, or the Sun book J2EE Connector Architecture and Enterprise Application Integration.
If you do go down the route of writing a JCA adapter, make sure you also read up on XA, such as Mike Spilles articles here:
http://www.theserverside.com/news/thread.tss?thread_id=23341

Similar Messages

  • Distributed transactions and 2-phase commit in a SAP Netweaver environment

    Hello,
    I am a Java architect., I don't know very much the SAP technologies. I tried to found on forums or technical papers if SAP does support distributed transactions and two-phase commit, it's not clear. I found something on SAP WAS but my project is using a  SAP PI 7.0 and I cannot find anything on the subject.
    My goal is to include a SAP server (via PI 7.0) in a distributed transaction handled by a J2EE ESB (Oracle, ex-BEA Aqualogic) based on XA capabilities.
    Does anyone have experience or feedback on this topic ?
    Thanks.

    Hi,
    Do you know this white paper ?
    [Distributed Transaction and 2 phase commit|https://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/3732d690-0201-0010-a993-b92aab79701f]
    Regards,
    Olivier

  • Topics on EP and the sequence to be followed

    Hi ,
       I have explored a few topics on the development side of the portal and there are a few on my mind .What I wish to know is if I have to develop a team of delivery capability then in what sequence these topics are to be taken with the team . I am listing the topics below . Please guide as I have never been on a project on EP so I am not aware about the importance of these topics and the sequence to be followed while taking them up with a team .
    Iviews : These include
    Making iviews using standard templates available .
    Making iviews using visual composer .
    Making customised iviews using PDK(NDS and WAS) .
    Webdynpro application
    JSPDynpage
    Business Packages
    Integration of Third party applications
    Configuring your mail server with the portal .Learning the configurational concepts of the exchange server .
    BSP applications
    HTMLB and tableviews
    BISDK and XMLA
    Using JCO and JCA
    Knowledge/content management
    Collaboration
    TREX
    If you have some other topics in mind please feel free to include here and also specify where do you wish to include them in the sequence . I need to know how do we go about this as it becomes quite confusing as to what to persue and with what importance as I have never faced a real time client requirements.
    I AM LOOKING FOR AN EXPERT ADVICE HERE .
    Regards
    Deepak Singh

    Hi deepak
    I think you can go for this sequence
    Making iviews(Making iviews using standard templates available .) and other pcd objects like worksets,pages etc..
    Creating users,roles and Assinging  roles to users
    Making iviews using visual composer.
    Knowledge/content management
    Customization of portal.
    Webdynpro application
    JSPDynpage,HTMLB and tableviews
    Making customised iviews using PDK(NDS and WAS).
    Using JCO and JCA
    Creating systems
    Configuring your mail server with the portal.Learning the configurational concepts of the exchange server .
    Integration of Third party applications
    Collaboration
    TREX
    Business Packages
    BSP applications
    BISDK and XMLA
    Regards
    Geogi

  • My credit card  has been charged for book, however my purchase history shows no record of the transaction and I have not received the book. The online problem reporting system does not have options to report this incident. Who can I cal

    My credit card  has been charged for book, however my purchase history shows no record of the transaction and I have not received the book. The online problem reporting system does not have options to report this incident. Who can I call?

    Would be problems with purchases, billing, and redemption option.  It's not 100% exact to your issue, but it will get you to the right department.
    Go here https://expresslane.apple.com/GetproductgroupList.do then select ITunes, then Store, then Purchases, Billing, and Redemption.  Then.. probably pick "My topic is not listed." 

  • Error while converting class file to exp and jca file

    error while converting *.class file to *.exp and *.jca file
    =====================================================================================================================
    linux-y60u:/home/admin/java_card_kit-2_2_1/samples/src # converter -exportpath "/home/admin/java_card_kit-2_2_1/lib/" com/sun/javacard/samples/HelloWorld 0x00:0x01:0x02:0x03:0x04:0x05:0x06:0x07:0x0b 1.0 -v -applet 0x00:0x01:0x02:0x03:0x04:0x05:0x06:0x07:0x0b:0x01 Identity
    Java Card 2.2.1 Class File Converter, Version 1.3
    Copyright 2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.
    parsing /home/admin/java_card_kit-2_2_1/samples/src/com/sun/javacard/samples/HelloWorld/HelloWorld.class
    parsing /home/admin/java_card_kit-2_2_1/samples/src/com/sun/javacard/samples/HelloWorld/Identity.class
    error: com.sun.javacard.samples.HelloWorld.HelloWorld: unsupported class file format of version 50.0.
    error: com.sun.javacard.samples.HelloWorld.Identity: unsupported class file format of version 50.0.
    conversion completed with 2 errors and 0 warnings.
    =====================================================================================================================

    i compile a file javacard use this command:
    ===
    javac -source 1.3 -target 1.1 -g -classpath ./classes:../lib/api.jar:../lib/installer.jar src/com/sun/javacard/samples/Identity/Identity.java
    ===
    and try to convert this class use this command
    ===
    /home/xnuxerx/admin/java_card_kit-2_2_1/bin/converter -exportpath "/home/xnuxerx/admin/java_card_kit-2_2_1/lib/" com/sun/javacard/samples/Identity 0x00:0x01:0x02:0x03:0x04:0x05:0x06:0x07:0x0b 1.0 -v -applet 0x00:0x01:0x02:0x03:0x04:0x05:0x06:0x07:0x0b:0x01 Identity
    ===
    result convert:
    ===
    Java Card 2.2.1 Class File Converter, Version 1.3
    Copyright 2003 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.
    parsing /home/xnuxerx/admin/java_card_kit-2_2_1/samples/classes/com/sun/javacard/samples/Identity/Identity.class
    converting com.sun.javacard.samples.Identity.Identity
    error: export file framework.exp of package javacard.framework not found.
    conversion completed with 1 errors and 0 warnings.
    ===
    why ??
    please your comment for this problem.
    thank 4 all.

  • What is difference between enjoy transactions and Normal transactions

    What is difference between enjoy transactions and Normal transactions
    Ex:- ME22 & ME22N
    What is difference between these two.

    hi ,
    the transaction code with 'N' are created with help of object concept.
    In your case ME22 is obsolete one and ME22N is the tcode created with object concept.
    pls Reward helpful points
    Thanks
    Siva

  • Open AR transaction and Receipts

    Can you let me know the standard concurrent programs which list all the Receivables Open AR Transaction and Open AR Receipts

    The table ar_payment_Schedules_all gives you the outstanding information as on date. For eg. if the system date is 13th April and if you query the ar_payment_schedules_all table, the amount_due_remaining column will give you the open amount as on that date.
    However if you want the oustanding as on some previous date, lets say as on 31st March, in that case you have to rollback all the applications that would have occured from 1st april to 13th april.
    Find below the script that I used to get the oustanding as on any previous date. Pls. note that I am using a temp table here to populate the details.
    declare
    v_cash_receipt NUMBER;
    v_adjustment NUMBER;
    v_credit_memo NUMBER;
    v_as_of_outstanding NUMBER;
    v_cash_receipt_acctd NUMBER;
    v_adjustment_acctd NUMBER;
    v_credit_memo_acctd NUMBER;
    v_credit_memo_acctd_1               NUMBER;
    v_as_of_outstanding_acctd NUMBER;
    p_as_of_date                          DATE;
    cursor cs_get_trx (p_as_of_date1 IN Date) is
    SELECT ps.customer_id CUST_ACCOUNT_ID
    , trx.creation_date INV_CREATION_DATE
    , ps.trx_number INVOICE_NUMBER
    , trx.trx_date                              INVOICE_DATE
    , ps.gl_date GL_DATE
    , NVL(ps.amount_due_original,0) INVOICE_AMOUNT
    , NVL(ps.tax_original,0) TAX_AMOUNT
    , NVL(ps.acctd_amount_due_remaining,0) ACCTD_OUTSTANDING_AMOUNT
    , ps.due_date
    , CEIL(sysdate - ps.due_date) DAYS_OUTSTANDING
    , ps.payment_schedule_id
    , ps.number_of_due_dates INSTALLMENT_NUMBER
    , trx.customer_trx_id
    , CEIL(p_as_of_date1 - ps.due_date) DAYS_LATE_AS_OF
    FROM ra_customer_trx TRX
    , ar_payment_schedules PS
    WHERE
    trx.customer_trx_id = ps.customer_trx_id
    AND ps.gl_date <= p_as_of_date1
    AND ps.gl_date_closed > p_as_of_date1 ;
    CURSOR cs_get_receipt(p_as_of_date2 IN DATE ) IS
    SELECT ps.customer_id CUST_ACCOUNT_ID
    , ps.payment_schedule_id
    , CEIL(p_as_of_date - ps.GL_DATE) days_late_as_of_r
    , ps.gl_date
    , cr.receipt_number
    , app.cash_receipt_id
    , sum(app.acctd_amount_applied_from) ACCTD_AMOUNT_APPLIED
    FROM ar_receivable_applications app
    , ar_cash_receipts cr
    , ar_payment_schedules ps
    WHERE app.cash_receipt_id = cr.cash_receipt_id
    AND app.payment_schedule_id = ps.payment_schedule_id
    AND app.status in ('ACC', 'UNAPP', 'UNID', 'OTHER ACC' )
    AND NVL(app.confirmed_flag,'Y') = 'Y'
    AND app.gl_date <= p_as_of_date2
    AND ps.gl_date <= p_as_of_date2
    AND ps.gl_date_closed > p_as_of_date2
    AND ( ( app.reversal_gl_date IS NOT NULL AND ps.gl_date <= p_as_of_date2 )
    OR app.reversal_gl_date IS NULL
    GROUP BY ps.customer_id
    , cr.receipt_number
    , app.cash_receipt_id
    , ps.payment_schedule_id
    , ps.gl_date
    HAVING
    sum(app.acctd_amount_applied_from) <> 0 ;
    Begin
    delete zxc_aging_cust1 ;
    p_as_of_date := to_date('&Enter_as_of_date','DD-MON-RRRR') ;
         For invoice in cs_get_trx(p_as_of_date)
         LOOP
    /* cash applied after p_as_of_date */
    SELECT NVL(SUM(NVL(acctd_amount_applied_to, 0.0) +
    NVL(acctd_earned_discount_taken,0.0) +
    NVL(acctd_unearned_discount_taken,0.0)),0.0)
    INTO v_cash_receipt_acctd
    FROM ar_receivable_applications
    WHERE TRUNC(gl_date) > p_as_of_date
    AND status||'' = 'APP'
    AND NVL(confirmed_flag,'Y') = 'Y'
    AND applied_payment_schedule_id = invoice.payment_schedule_id
    AND application_type LIKE 'CASH%';
    /* adjustments applied after p_as_of_date */
    SELECT NVL(SUM(ar_adjustments.acctd_amount), 0.0)
    INTO v_adjustment_acctd
    FROM ar_adjustments
    WHERE TRUNC(gl_date) > p_as_of_date
    AND status = 'A'
    AND payment_schedule_id = invoice.payment_schedule_id;
    /* invoice credited after p_as_of_date */
    SELECT nvl(sum(nvl(acctd_amount_applied_to, 0.0)), 0.0)
    INTO v_credit_memo_acctd
    FROM ar_receivable_applications
    WHERE applied_payment_schedule_id = invoice.payment_schedule_id
    AND nvl(confirmed_flag,'Y') = 'Y'
    AND status||'' = 'APP'
    AND TRUNC(gl_date) > p_as_of_date
    AND application_type LIKE 'CM%';
    /*added new by anil patil 7/7/7 */
    /* credit memo applied after p_as_of_date */
    SELECT nvl(sum(nvl(acctd_amount_applied_to, 0.0)), 0.0)
    INTO v_credit_memo_acctd_1
    FROM ar_receivable_applications
    WHERE payment_schedule_id = invoice.payment_schedule_id
    AND nvl(confirmed_flag,'Y') = 'Y'
    AND status||'' = 'APP'
    AND TRUNC(gl_date) > p_as_of_date
    AND application_type LIKE 'CM%';
    /* calculate actual outstanding amount */
    v_as_of_outstanding_acctd := invoice.acctd_outstanding_amount + v_cash_receipt_acctd - v_adjustment_acctd +
                                            v_credit_memo_acctd - v_credit_memo_acctd_1 ;
    insert into zxc_aging_cust1
    ( customer_id ,
    invoice_number     ,
              invoice_date ,
              gl_date          ,
              invoice_amount ,
              tax_amount ,
              acctd_outstanding_amount ,
              due_date     ,
              days_outstanding ,
              installment_number ,
              days_late_as_of ,
              current_os_amt ,
              cash_receipt_amt ,
              adj_amt ,
              credit_memo_amt ,
              credit_memo_amt_1
    values
              (invoice.cust_account_id ,
              invoice.invoice_number     ,
              invoice.invoice_date ,
              invoice.gl_date          ,
              invoice.invoice_amount ,
              invoice.tax_amount ,
              v_as_of_outstanding_acctd ,
              invoice.due_date     ,
              invoice.days_outstanding ,
              invoice.installment_number ,
              invoice.days_late_as_of ,
              invoice.acctd_outstanding_amount ,
              v_cash_receipt_acctd ,
              v_adjustment_acctd ,
              v_credit_memo_acctd ,
              v_credit_memo_acctd_1
         END LOOP ;
    COMMIT;
    FOR receipt in cs_get_receipt (p_as_of_date )
    LOOP
         INSERT INTO zxc_aging_cust1( customer_id
    , invoice_number
    , trx_type
    , acctd_outstanding_amount
    , gl_date
         VALUES( receipt.cust_account_id
    , receipt.receipt_number
    , 'RECEIPT'
    , -1 * receipt.acctd_amount_applied
    , receipt.gl_date );
    END LOOP;
    COMMIT ;
    END;
    Hope this helps.
    Thanks,
    Anil

  • Material Transaction and Move Transaction Managers are Going Inactive

    hi
    it was running previously but currently it becomes inactive.can any one tell in which table to look for the error related to this problem?
    Kind Regards
    Sayantan

    Hi;
    What is your OS and EBS?
    It was working before? If yes what have you been changed on your system(patch etc)
    Please check below note:
    Material Transaction And Move Transaction Managers Are Going Inactive [ID 93507.1]
    Material Transaction and Move Transaction Managers are Going Inactive [ID 98757.1]
    Regard
    Helios

  • Re: Transactions and Locking Rows for Update

    Dale,
    Sounds like you either need an "optimistic locking" scheme, usually
    implemented with timestamps at the database level, or a concurrency manager.
    A concurrency manager registers objects that may be of interest to multiple
    users in a central location. It takes care of notifying interested parties
    (i.e., clients,) of changes made to those objects, using a "notifier" pattern.
    The optimistic locking scheme is relatively easy to implement at the
    database level, but introduces several problems. One problem is that the
    first person to save their changes "wins" - every one else has to discard
    their changes. Also, you now have business policy effectively embedded in
    the database.
    The concurrency manager is much more flexible, and keeps the policy where
    it probably belongs. However, it is more complex, and there are some
    implications to performance when you get to the multiple-thousand-user
    range because of its event-based nature.
    Another pattern of lock management that has been implemented is a
    "key-based" lock manager that does not use events, and may be more
    effective at managing this type of concurrency for large numbers of users.
    There are too many details to go into here, but I may be able to give you
    more ideas in a separate note, if you want.
    Don
    At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
    I have a problem in the application I am currently working on, which it
    seems to me should be easily solvable via appropriate use of transactions
    and database locking, but I'm having trouble figuring out exactly how to
    do it. The database we are using is Oracle 7.2.
    The scenario is as follows: We have a window where the user picks an
    object from a dropdown list. Some of the object's attributes are then
    displayed in that window, and the user then has the option of editing
    those attributes, and at some point hitting the equivalent of a 'save'button
    to write the changes back to the database. So far, so good. Now
    introduce a second user. If user #1 and user #2 both happen to pull up
    the same object and start making changes to it, user #1 could write back
    to the database and then 15 seconds later user #2 could write back to the
    database, completely overlaying user #1's changes without ever knowing
    they had happened. This is not good, particularly for our application
    where editing the object causes it to progress from one state to the next,
    and multiple users trying to edit it at the same time spells disaster.
    The first thing that came to mind was to do a select with intent to update,
    i.e. 'select * from table where key = 'somevalue' with update'. This way
    the next user to try to select from the table using the same key would not
    be able to get it. This would prevent multiple users from being able to
    pull the same object up on their screens at the same time. Unfortunately,
    I can think of a number of problems with this approach.
    For one thing, the lock is only held for the duration of the transaction, so
    I would have to open a Forte transaction, do the select with intent to
    update, let the user modify the object, then when they saved it back again
    end the transaction. Since a window is driven by the event loop I can't
    think of any way to start a transaction, let the user interact with the
    window, then end the transaction, short of closing and re-opening the
    window. This would imply having a separate window specifically for
    updating the object, and then wrapping the whole of that window's event
    loop in a transaction. This would be a different interface than we wanted
    to present to the users, but it might still work if not for the next issue.
    The second problem is that we are using a pooled DBSession approach
    to connecting to the database. There is a single Oracle login account
    which none of the users know the password to, and thus the users
    simply share DBSession resources. If one user starts a transaction
    and does a select with intent to update on one DBSession, then another
    user starts a transaction and tries to do the same thing on the same
    DBSession, then the second user will get an error out of Oracle because
    there's already an open transaction on that DBSession.
    At this point, I am still tossing ideas around in my head, but after
    speaking with our Oracle/Forte admin here, we came to the conclusion
    that somebody must have had to address these issues before, so I
    thought I'd toss it out and see what came back.
    Thanks in advance for any ideas!
    Dale V. Georg
    Indus Consultancy Services [email protected]
    Mack Trucks, Inc. [email protected]
    >
    >
    >
    >
    ====================================
    Don Nelson
    Senior Consultant
    Forte Software, Inc.
    Denver, CO
    Corporate voice mail: 510-986-3810
    aka: [email protected]
    ====================================
    "I think nighttime is dark so you can imagine your fears with less
    distraction." - Calvin

    We have taken an optimistic data locking approach. Retrieved values are
    stored as initial values; changes are stored seperately. During update, key
    value(s) or the entire retieved set is used in a where criteria to validate
    that the data set is still in the initial state. This allows good decoupling
    of the data access layer. However, optimistic locking allows multiple users
    to access the same data set at the same time, but then only one can save
    changes, the rest would get an error message that the data had changed. We
    haven't had any need to use a pessimistic lock.
    Pessimistic locking usually involves some form of open session or DBMS level
    lock, which we haven't implemented for performance reasons. If we do find the
    need for a pessimistic lock, we will probably use cached data sets that are
    checked first, and returned as read-only if already in the cache.
    -DFR
    Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
    To: Forte User Group <[email protected]> @ INTERNET
    cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
    Steve <[email protected]> @ INTERNET
    Subject: Transactions and Locking Rows for Update
    I have a problem in the application I am currently working on, which it
    seems to me should be easily solvable via appropriate use of transactions
    and database locking, but I'm having trouble figuring out exactly how to
    do it. The database we are using is Oracle 7.2.
    The scenario is as follows: We have a window where the user picks an
    object from a dropdown list. Some of the object's attributes are then
    displayed in that window, and the user then has the option of editing
    those attributes, and at some point hitting the equivalent of a 'save' button
    to write the changes back to the database. So far, so good. Now
    introduce a second user. If user #1 and user #2 both happen to pull up
    the same object and start making changes to it, user #1 could write back
    to the database and then 15 seconds later user #2 could write back to the
    database, completely overlaying user #1's changes without ever knowing
    they had happened. This is not good, particularly for our application
    where editing the object causes it to progress from one state to the next,
    and multiple users trying to edit it at the same time spells disaster.
    The first thing that came to mind was to do a select with intent to update,
    i.e. 'select * from table where key = 'somevalue' with update'. This way
    the next user to try to select from the table using the same key would not
    be able to get it. This would prevent multiple users from being able to
    pull the same object up on their screens at the same time. Unfortunately,
    I can think of a number of problems with this approach.
    For one thing, the lock is only held for the duration of the transaction, so
    I would have to open a Forte transaction, do the select with intent to
    update, let the user modify the object, then when they saved it back again
    end the transaction. Since a window is driven by the event loop I can't
    think of any way to start a transaction, let the user interact with the
    window, then end the transaction, short of closing and re-opening the
    window. This would imply having a separate window specifically for
    updating the object, and then wrapping the whole of that window's event
    loop in a transaction. This would be a different interface than we wanted
    to present to the users, but it might still work if not for the next issue.
    The second problem is that we are using a pooled DBSession approach
    to connecting to the database. There is a single Oracle login account
    which none of the users know the password to, and thus the users
    simply share DBSession resources. If one user starts a transaction
    and does a select with intent to update on one DBSession, then another
    user starts a transaction and tries to do the same thing on the same
    DBSession, then the second user will get an error out of Oracle because
    there's already an open transaction on that DBSession.
    At this point, I am still tossing ideas around in my head, but after
    speaking with our Oracle/Forte admin here, we came to the conclusion
    that somebody must have had to address these issues before, so I
    thought I'd toss it out and see what came back.
    Thanks in advance for
    any
    ideas!
    Dale V. Georg
    Indus Consultancy Services [email protected]
    Mack Trucks, Inc. [email protected]
    ------ Message Header Follows ------
    Received: from pebble.Sagesoln.com by notes.bsginc.com
    (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
    id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
    Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
    NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
    Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
    NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
    Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
    id sma011817; Thu Jun 5 13:47:43 1997
    Received: from tes0001.macktrucks.com by relay.macktrucks.com
    via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
    1997 19:35:31 UT
    Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
    id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
    Message-ID: <[email protected]>
    Priority: Normal
    To: Forte User Group <[email protected]>
    Cc: "Richards," Debbie <[email protected]>,
    "Gardner," Steve <[email protected]>
    MIME-Version: 1.0
    From: Dale "V." Georg <[email protected]>
    Subject: Transactions and Locking Rows for Update
    Date: Thu, 05 Jun 97 16:48:37 PDT
    Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
    Content-Transfer-Encoding: quoted-printable
    Sender: [email protected]
    Precedence: bulk
    Reply-To: Dale "V." Georg <[email protected]>

  • Transactions and Locking Rows for Update

    I have a problem in the application I am currently working on, which it
    seems to me should be easily solvable via appropriate use of transactions
    and database locking, but I'm having trouble figuring out exactly how to
    do it. The database we are using is Oracle 7.2.
    The scenario is as follows: We have a window where the user picks an
    object from a dropdown list. Some of the object's attributes are then
    displayed in that window, and the user then has the option of editing
    those attributes, and at some point hitting the equivalent of a 'save' button
    to write the changes back to the database. So far, so good. Now
    introduce a second user. If user #1 and user #2 both happen to pull up
    the same object and start making changes to it, user #1 could write back
    to the database and then 15 seconds later user #2 could write back to the
    database, completely overlaying user #1's changes without ever knowing
    they had happened. This is not good, particularly for our application
    where editing the object causes it to progress from one state to the next,
    and multiple users trying to edit it at the same time spells disaster.
    The first thing that came to mind was to do a select with intent to update,
    i.e. 'select * from table where key = 'somevalue' with update'. This way
    the next user to try to select from the table using the same key would not
    be able to get it. This would prevent multiple users from being able to
    pull the same object up on their screens at the same time. Unfortunately,
    I can think of a number of problems with this approach.
    For one thing, the lock is only held for the duration of the transaction, so
    I would have to open a Forte transaction, do the select with intent to
    update, let the user modify the object, then when they saved it back again
    end the transaction. Since a window is driven by the event loop I can't
    think of any way to start a transaction, let the user interact with the
    window, then end the transaction, short of closing and re-opening the
    window. This would imply having a separate window specifically for
    updating the object, and then wrapping the whole of that window's event
    loop in a transaction. This would be a different interface than we wanted
    to present to the users, but it might still work if not for the next issue.
    The second problem is that we are using a pooled DBSession approach
    to connecting to the database. There is a single Oracle login account
    which none of the users know the password to, and thus the users
    simply share DBSession resources. If one user starts a transaction
    and does a select with intent to update on one DBSession, then another
    user starts a transaction and tries to do the same thing on the same
    DBSession, then the second user will get an error out of Oracle because
    there's already an open transaction on that DBSession.
    At this point, I am still tossing ideas around in my head, but after
    speaking with our Oracle/Forte admin here, we came to the conclusion
    that somebody must have had to address these issues before, so I
    thought I'd toss it out and see what came back.
    Thanks in advance for any ideas!
    Dale V. Georg
    Indus Consultancy Services [email protected]
    Mack Trucks, Inc. [email protected]
    [email protected]------------------

    I have a problem in the application I am currently working on, which it
    seems to me should be easily solvable via appropriate use of transactions
    and database locking, but I'm having trouble figuring out exactly how to
    do it. The database we are using is Oracle 7.2.
    The scenario is as follows: We have a window where the user picks an
    object from a dropdown list. Some of the object's attributes are then
    displayed in that window, and the user then has the option of editing
    those attributes, and at some point hitting the equivalent of a 'save' button
    to write the changes back to the database. So far, so good. Now
    introduce a second user. If user #1 and user #2 both happen to pull up
    the same object and start making changes to it, user #1 could write back
    to the database and then 15 seconds later user #2 could write back to the
    database, completely overlaying user #1's changes without ever knowing
    they had happened. This is not good, particularly for our application
    where editing the object causes it to progress from one state to the next,
    and multiple users trying to edit it at the same time spells disaster.
    The first thing that came to mind was to do a select with intent to update,
    i.e. 'select * from table where key = 'somevalue' with update'. This way
    the next user to try to select from the table using the same key would not
    be able to get it. This would prevent multiple users from being able to
    pull the same object up on their screens at the same time. Unfortunately,
    I can think of a number of problems with this approach.
    For one thing, the lock is only held for the duration of the transaction, so
    I would have to open a Forte transaction, do the select with intent to
    update, let the user modify the object, then when they saved it back again
    end the transaction. Since a window is driven by the event loop I can't
    think of any way to start a transaction, let the user interact with the
    window, then end the transaction, short of closing and re-opening the
    window. This would imply having a separate window specifically for
    updating the object, and then wrapping the whole of that window's event
    loop in a transaction. This would be a different interface than we wanted
    to present to the users, but it might still work if not for the next issue.
    The second problem is that we are using a pooled DBSession approach
    to connecting to the database. There is a single Oracle login account
    which none of the users know the password to, and thus the users
    simply share DBSession resources. If one user starts a transaction
    and does a select with intent to update on one DBSession, then another
    user starts a transaction and tries to do the same thing on the same
    DBSession, then the second user will get an error out of Oracle because
    there's already an open transaction on that DBSession.
    At this point, I am still tossing ideas around in my head, but after
    speaking with our Oracle/Forte admin here, we came to the conclusion
    that somebody must have had to address these issues before, so I
    thought I'd toss it out and see what came back.
    Thanks in advance for any ideas!
    Dale V. Georg
    Indus Consultancy Services [email protected]
    Mack Trucks, Inc. [email protected]
    [email protected]------------------

  • Error : Excise modvat accounts not defined for GRPO transaction and U1 exci

    I have Created Impot PO, After Planned Delivery cost MIRO I am trying to Perform GR then its giving Error "Excise modvat accounts not defined for GRPO transaction and U1 excise group
    Message no. 8I402"
          I have already maintained GL account in "Specify G/L Accounts per Excise Transaction" for Excise group U1
          This problem is coming when Additional Duty on custom condition type JADC is maintained in "Maintain Excise Defaults" node in the column "ADC Cond" . If I remove JADC condition type from this place the this error is not coming but AED column is not fetching any value while doing GR.
    Please help me in this issue , still No answer
    Edited by: shiwanshu singh on Jan 28, 2009 10:26 AM

    Dear sir
    For GRPO have you maintained sub transaction Type IP for your excise group U1. If you not maintained pl maintain . and assign G/L account to modvat clearing account , the G/l account should be same as company code CVD account.
    Regards
    jrp

  • Excise modvat accounts not defined for GRPO transaction and 58 Excise group

    Hi Experts,
    When i am doing Goods receipts for Depot for Subcontracting
    i am getting this error message .Excise modvat accounts not defined for GRPO transaction and  Excise group. For Depot no modvat. is there any configuration setting for depot. Please do needful.

    Hi,
    Please maintain
    Hi,
    go to SPRO
    Specify G/L Accounts per Excise Transaction
    SPROLogistics u2013 GeneralTax on Goods MovementsIndia Account Determination  Specify G/L Accounts per Excise Transaction
    Enter excise group -58
    ETT_ GRPO
    and G/L account
    G.Ganesh Kumar

  • Excise modvat accounts not defined for DLFC transaction and excise group

    Dear Experts,
    Iam raising this question after checking all the contents related to Sub Transaction type in SDN.
    My prob is: for raw material sales scenario i have created order delivery and invoice. For Invoice i have done account determination with a different G/L in VKOA. Now i have to create an excise invoice and the accounting entry for central ED on sales should go to different G/L account. for account determination i have done the following settings:
    Maintained Sub transaction type in
    IMG -> Logistics - General -> Tax on Goods movement -> India -> Basic Settings
    ->Maintain Sub Transaction types
    IMG -> Logistics - General -> Tax on Goods movement -> India ->
    Account determination -> Specify Excise Accounts per Excise Transaction.
    Here against DLFC sub transaction Type is maintained..
    Also
    IMG -> Logistics - General -> Tax on Goods movement -> India -> Account determination -> Specify G/L Accounts per Excise Transaction
    Here maintained Excise group with DLFC Company Code subtransaction type, chart of accounts and all required GL Account .
    But when the iam creating Excise Invoice in J1IIN and clicking on Subtransaction type-F4, no entries are shown. No values found is the message in green. Message no. DH801
    If i use subtransaction type and enter billing document and enter, the following error message comes:
    "Excise modvat accounts not defined for DLFC transaction and excise group"
    Iam unable to understand why the subtransaction type maintained is not showing in TCODE J1IIN?
    Regards

    For the error message DH801, please check note 840911
    Excise modvat accounts not defined for
           DLFC transaction and excise group"
    Please check  your G/L assignments "Specify G/L Accounts per Excise Transaction"
    thanks
    G. Lakshmipathi

  • Excise modvat accounts not defined for CAPE transaction and TS excise group

    Hi Guys,
    Suddenly we are facing issue during exicse invoice capturing with MIGO
    system is giving following error
    "Excise modvat accounts not defined for CAPE transaction and TS excise group
    Message no. 8I402
    While in Excise account assignment table CAPE is Linked to Modvat Clearing Account which is further liked to correct GL
    Can any one explain the cause of this issue Points will be awarded
    Regards,
    Ashish

    Hi
    Pls maintain the following:
    1. SPRO->Logistics General -> Tax on Goods Movements -> India -> Account Determination -> Specify Excise Accounts per Excise Transaction
    Pls note the Sub Tansaction type is IP for ETT CAPE.
    ETT  <b>Sub Trn Type</b>   DC Ind                Account Name
    CAPE     IP           CR Credit     ONHOLD CENVAT on hold account
    CAPE     IP           DR Debit     ONHOLD CENVAT on hold account
    CAPE     IP           DR Debit     RG23AED RG 23 AED account
    CAPE     IP           DR Debit     RG23BED RG 23 BED account
    CAPE     IP           DR Debit     RG23SED RG 23 SED account
    CAPE       IP                   DR Debit             RG23ECS RG 23 ECS account
    2. SPRO->Logistics General -> Tax on Goods Movements -> India -> Account Determination -> Specify G/L Accounts per Excise Transaction
    Check the G/L accounts for Excise Transaction Type CAPE and maintain the same G/L accounts for ETT CAPE with <b>Sub Trn Type IP</b>.
    Hope this clarifies.
    Thanks

  • Error - Excise modvat accounts not defined for DLFC transaction and 01 exci

    Dear All,
    Getting below error while  doing J1IIN - Posting Excise invoice for Sale.
    "Excise modvat accounts not defined for DLFC transaction and 01 excise group"
    I checked with the settings GL are assigned to for DLFC and 01 excise group.
    Is anywhere else I need to mantain the modvat GL
    Regards,
    Rakesh

    Check if you are using any subtransaction type along with excise transaction type.
    Excise group, ETT, company code, sub transaction type (if any), Chart of account, Modvat account (pls maintain all the entries over here) search for modavat clearing field and maintain it.
    BR
    Edited by: Sujoy on Jan 15, 2010 9:45 AM

Maybe you are looking for