Setting db isolation level on transaction without EJB

          I'm using UserTransaction in the servlet container, to control XA transactions.
          We're not using EJB. How do I set the database isolation level? I'm tempted
          to use java.sql.Connection.setTransactionIsolation(). However, the Sun Javadoc
          for that method says you can't call that after the transaction has started (which
          makes sense). Right now, we're starting the transaction, getting a connection,
          closing the connection, and committing the transaction. I guess that order won't
          work if I want to set the isolation level. Or am I mixing apples and oranges
          here? If I use UserTransaction, is it even appropriate to try to set the isolation
          level on the connection?
          All I really want to do is change the default isolation level. We do not need
          different isolation levels for different use cases. (Not yet, anyway.) We might
          have transactions against two different database instances or other resource managers.
          That's why I want to use UserTransaction and XA transactions.
          Thanks!
          Steve Molitor
          [email protected]
          

Only committed transactions are replicated to the subscriber.  But it is possible for the report to see dirty data if running in READ UNCOMMITTED or NOLOCK.  You should run your reports in READ COMMITTED or SNAPSHOT isolation , and your replication
subscriber should be configured with READ COMMITTED SNAPSHOT ISLOATION eg
alter database MySubscriber set allow_snapshot_isolation on;
alter database MySubscriber set read_committed_snapshot on;
as recommended here
Enhance General Replication Performance.
David
David http://blogs.msdn.com/b/dbrowne/

Similar Messages

  • How to set the isolation level on Entity EJBs

    I am using 10.1.3.3 of the OC4J app server.
    I am creating an application that uses EJB 2.1.
    I am trying to set the isolation levels on the EJBs to either serializable or repeatable read.
    When i deploy the EAR file from the OC4J admin console, i can set the isolation level property on the EJB's however when i inspect the orion-ejb-jar.xml file I do not see the isolation level being set. Furthermore, i tried to manually change the isolation setting by editing the orion-ejb-jar.xml and adding the isolation="serialiable" attribute on the entity bean descriptor. I then stopped and restarted the server. I noticed that my change was no longer in the file.
    Can someone please let me know how to solve this problem and set the isolation level on Entity EJBs . Thanks

    I find it at ejb.pdf from BEA.
              The transaction-isolation stanza can contain the elements shown here:
              <transaction-isolation>
              <isolation-level>Serializable</isolation-level>
              <method>
              <description>...</description>
              <ejb-name>...</ejb-name>
              <method-intf>...</method-intf>
              <method-name>...</method-name>
              <method-params>...</method-params>
              </method>
              </transaction-isolation>
              "Hyun Min" <[email protected]> wrote in message
              news:3c4e7a83$[email protected]..
              > Hi!
              >
              > I have a question.
              > How to set the transaction isolation level using CMT in descriptor?
              >
              > The Isolation level not supported in CMT?
              >
              > Thanks.
              > Hyun Min
              >
              >
              

  • Setting the isolation level in Toplink or in my EJB beans?

    Hi,
    Seems like you can set the isolation levels in both Toplink and in the deployment descriptor of your ejb project.
    What is the recommended place to specify the isolation level settings?
    With kind regards.

    Hi,
    Seems like you can set the isolation levels in both Toplink and in the deployment descriptor of your ejb project.
    What is the recommended place to specify the isolation level settings?
    With kind regards.

  • Changing Isolation Level Mid-Transaction

    Hi,
    I have a SS bean which, within a single container managed transaction, makes numerous
    database accesses. Under high load, we start having serious contention issues
    on our MS SQL server database. In order to reduce these issues, I would like
    to reduce my isolation requirements in some of the steps of the transaction.
    To my knowledge, there are two ways to achieve this: a) specify isolation at the
    connection level, or b) use locking hints such as NOLOCK or ROWLOCK in the SQL
    statements. My questions are:
    1) If all db access is done within a single tx, can the isolation level be changed
    back and forth?
    2) Is it best to set the isolation level at the JDBC level or to use the MS SQL
    locking hints?
    Is there any other solution I'm missing?
    Thanks,
    Sebastien

    Galen Boyer wrote:
    On Sun, 28 Mar 2004, [email protected] wrote:
    Galen Boyer wrote:
    On Wed, 24 Mar 2004, [email protected] wrote:
    Oracle's serializable isolation level doesn't offer what most
    customers I've seen expect it to offer. They typically expect
    that a serializable transaction will block any read-data from
    being altered during the transaction, and oracle doesn't do
    that.I haven't implemented WEB systems that employ anything but
    the default concurrency control, because a web transaction is
    usually very long running and therefore holding a connection
    open during its life is unscalable. But, your statement did
    make me curious. I tried a quick test case. IN ONE SQLPLUS
    SESSION: SQL> alter session set isolation_level =
    serializable; SQL> select * from t1; ID FL ---------- -- 1 AA
    2 BB 3 CC NOW, IN ANOTHER SQLPLUS SESSION: SQL> update t1 set
    fld = 'YY' where id = 1; 1 row updated. SQL> commit; Commit
    complete. Now, back to the previous session. SQL> select *
    from t1; ID FL ---------- -- 1 AA 2 BB 3 CC So, your
    statement is incorrect.Hi, and thank you for the diligence to explore. No, actually
    you proved my point. If you did that with SQLServer or Sybase,
    your second session's update would have blocked until you
    committed your first session's transaction. Yes, but this doesn't have anything to do with serializable.
    This is the weak behaviour of those systems that say writers can
    block readers.Weak or strong, depending on the customer point of view. It does guarantee
    that the locking tx can continue, and read the real data, and eventually change
    it, if necessary without fear of blockage by another tx etc.
    In your example, you were able to change and commit the real
    data out from under the first, serializable transaction. The
    reason why your first transaction is still able to 'see the old
    value' after the second tx committed, is not because it's
    really the truth (else why did oracle allow you to commit the
    other session?). What you're seeing in the first transaction's
    repeat read is an obsolete copy of the data that the DBMS
    made when you first read it. Yes, this is true.
    Oracle copied that data at that time into the per-table,
    statically defined space that Tom spoke about. Until you commit
    that first transaction, some other session could drop the whole
    table and you'd never know it.This is incorrect.Thanks. Point taken. It is true that you could have done a complete delete
    of all rows in the table though..., correct?
    That's the fast-and-loose way oracle implements
    repeatable-read! My point is that almost everyone trying to
    serialize transactions wants the real data not to
    change. Okay, then you have to lock whatever you read, completely.
    SELECT FOR UPDATE will do this for your customers, but
    serializable won't. Is this the standard definition of
    serializable of just customer expectation of it? AFAIU,
    serializable protects you from overriding already committed
    data.The definition of serializable is loose enough to allow
    oracle's implementation, but non-changing relevant data is
    a typically understood hope for serializable. Serializable
    transactions typically involve reading and writing *only
    already committed data*. Only DIRTY_READ allows any access to
    pre-committed data. The point is that people assume that a
    serializable transaction will not have any of it's data re
    committed, ie: altered by some other tx, during the serializable
    tx.
    Oracle's rationale for allowing your example is the semantic
    arguement that in spite of the fact that your first transaction
    started first, and could continue indefinitely assuming it was
    still reading AA, BB, CC from that table, because even though
    the second transaction started later, the two transactions *so
    far*, could have been serialized. I believe they rationalize it by saying that the state of the
    data at the time the transaction started is the state throughout
    the transaction.Yes, but the customer assumes that the data is the data. The customer
    typically has no interest in a copy of the data staying the same
    throughout the transaction.
    Ie: If the second tx had started after your first had
    committed, everything would have been the same. This is true!
    However, depending on what your first tx goes on to do,
    depending on what assumptions it makes about the supposedly
    still current contents of that table, it may ether be wrong, or
    eventually do something that makes the two transactions
    inconsistent so they couldn't have been serialized. It is only
    at this later point that the first long-running transaction
    will be told "Oooops. This tx could not be serialized. Please
    start all over again". Other DBMSes will completely prevent
    that from happening. Their value is that when you say 'commit',
    there is almost no possibility of the commit failing. But this isn't the argument against Oracle. The unable to
    serialize doesn't happen at commit, it happens at write of
    already changed data. You don't have to wait until issuing
    commit, you just have to wait until you update the row already
    changed. But, yes, that can be longer than you might wish it to
    be. True. Unfortunately the typical application writer logic may
    do stuff which never changes the read data directly, but makes
    changes that are implicitly valid only when the read data is
    as it was read. Sometimes the logic is conditional so it may never
    write anything, but may depend on that read data staying the same.
    The issue is that some logic wants truely serialized transactions,
    which block each other on entry to the transaction, and with
    lots of DBMSes, the serializable isolation level allows the
    serialization to start with a read. Oracle provides "FOR UPDATE"
    which can supply this. It is just that most people don't know
    they need it.
    With Oracle and serializable, 'you pay your money and take your
    chances'. You don't lose your money, but you may lose a lot of
    time because of the deferred checking of serializable
    guarantees.
    Other than that, the clunky way that oracle saves temporary
    transaction-bookkeeping data in statically- defined per-table
    space causes odd problems we have to explain, such as when a
    complicated query requires more of this memory than has been
    alloted to the table(s) the DBMS will throw an exception
    saying it can't serialize the transaction. This can occur even
    if there is only one user logged into the DBMS.This one I thought was probably solved by database settings,
    so I did a quick search, and Tom Kyte was the first link I
    clicked and he seems to have dealt with this issue before.
    http://tinyurl.com/3xcb7 HE WRITES: serializable will give you
    repeatable read. Make sure you test lots with this, playing
    with the initrans on the objects to avoid the "cannot
    serialize access" errors you will get otherwise (in other
    databases, you will get "deadlocks", in Oracle "cannot
    serialize access") I would bet working with some DBAs, you
    could have gotten past the issues your client was having as
    you described above.Oh, yes, the workaround every time this occurs with another
    customer is to have them bump up the amount of that
    statically-defined memory. Yes, this is what I'm saying.
    This could be avoided if oracle implemented a dynamically
    self-adjusting DBMS-wide pool of short-term memory, or used
    more complex actual transaction logging. ? I think you are discounting just how complex their logging
    is. Well, it's not the logging that is too complicated, but rather
    too simple. The logging is just an alternative source of memory
    to use for intra-transaction bookkeeping. I'm just criticising
    the too-simpleminded fixed-per-table scratch memory for stale-
    read-data-fake-repeatable-read stuff. Clearly they could grow and
    release memory as needed for this.
    This issue is more just a weakness in oracle, rather than a
    deception, except that the error message becomes
    laughable/puzzling that the DBMS "cannot serialize a
    transaction" when there are no other transactions going on.Okay, the error message isn't all that great for this situation.
    I'm sure there are all sorts of cases where other DBMS's have
    laughable error messages. Have you submitted a TAR?Yes. Long ago! No one was interested in splitting the current
    message into two alternative messages:
    "This transaction has just become unserializable because
    of data changes we allowed some other transaction to do"
    or
    "We ran out of a fixed amount of scratch memory we associated
    with table XYZ during your transaction. There were no other
    related transactions (or maybe even users of the DBMS) at this
    time, so all you need to do to succeed in future is to have
    your DBA reconfigure this scratch memory to accomodate as much
    as we may need for this or any future transaction."
    I am definitely not an Oracle expert. If you can describe for
    me any application design that would benefit from Oracle's
    implementation of serializable isolation level, I'd be
    grateful. There may well be such.As I've said, I've been doing web apps for awhile now, and
    I'm not sure these lend themselves to that isolation level.
    Most web "transactions" involve client think-time which would
    mean holding a database connection, which would be the death
    of a web app.Oh absolutely. No transaction, even at default isolation,
    should involve human time if you want a generically scaleable
    system. But even with a to-think-time transaction, there is
    definitely cases where read-data are required to stay as-is for
    the duration. Typically DBMSes ensure this during
    repeatable-read and serializable isolation levels. For those
    demanding in-the-know customers, oracle provided the select
    "FOR UPDATE" workaround.Yep. I concur here. I just think you are singing the praises of
    other DBMS's, because of the way they implement serializable,
    when their implementations are really based on something that the
    Oracle corp believes is a fundamental weakness in their
    architecture, "Writers block readers". In Oracle, this never
    happens, and is probably one of the biggest reasons it is as
    world-class as it is, but then its behaviour on serializable
    makes you resort to SELECT FOR UPDATE. For me, the trade-off is
    easily accepted.Well, yes and no. Other DBMSes certainly have their share of faults.
    I am not critical only of oracle. If one starts with Oracle, and
    works from the start with their performance arcthitecture, you can
    certainly do well. I am only commenting on the common assumptions
    of migrators to oracle from many other DBMSes, who typically share
    assumptions of transactional integrity of read-data, and are surprised.
    If you know Oracle, you can (mostly) do everything, and well. It is
    not fundamentally worse, just different than most others. I have had
    major beefs about the oracle approach. For years, there was TAR about
    oracle's serializable isolation level *silently allowing partial
    transactions to commit*. This had to do with tx's that inserted a row,
    then updated it, all in the one tx. If you were just lucky enough
    to have the insert cause a page split in the index, the DBMS would
    use the old pre-split page to find the newly-inserted row for the
    update, and needless to say, wouldn't find it, so the update merrily
    updated zero rows! The support guy I talked to once said the developers
    wouldn't fix it "because it'd be hard". The bug request was marked
    internally as "must fix next release" and oracle updated this record
    for 4 successive releases to set the "next release" field to the next
    release! They then 'fixed' it to throw the 'cannot serialize' exception.
    They have finally really fixed it.( bug #440317 ) in case you can
    access the history. Back in 2000, Tom Kyte reproduced it in 7.3.4,
    8.0.3, 8.0.6 and 8.1.5.
    Now my beef is with their implementation of XA and what data they
    lock for in-doubt transactions (those that have done the prepare, but
    have not yet gotten a commit). Oracle's over-simple logging/locking is
    currently locking pages instead of rows! This is almost like Sybase's
    fatal failure of page-level locking. There can be logically unrelated data
    on those pages, that is blocked indefinitely from other equally
    unrelated transactions until the in-doubt tx is resolved. Our TAR has
    gotten a "We would have to completely rewrite our locking/logging to
    fix this, so it's your fault" response. They insist that the customer
    should know to configure their tables so there is only one datarow per
    page.
    So for historical and current reasons, I believe Oracle is absolutely
    the dominant DBMS, and a winner in the market, but got there by being first,
    sold well, and by being good enough. I wish there were more real market
    competition, and user pressure. Then oracle and other DBMS vendors would
    be quicker to make the product better.
    Joe

  • Setting XA isolation level.

    Is there a configuration parameter that controls the default isolation level used by distributed transactions when you configure XA support on Oracle 8i? I know Oracle's default isolation level is READ COMMITTED, but I would like to have SERIALIZABLE as the isolation level for transactions that are initiated from some MS COM+ components accessing the database.
    Thanks,
    Sam

    Ian,
    The default for Oracle (any version) is ReadCommitted. The only other
    isolation level Oracle supports is Serializable but it's implemented in
    such a way that you will be allowed to continue until commit time and
    only then you might get an exception stating the the access for that
    transaction could not be serialized.
    I don't know for the jDriver but if you use the Oracle Thin XA driver
    even if you set the isolation level in your descriptor you will get an
    exception from Weblogic. It is a Weblogic bug and you can contact
    [email protected] to get a patch.
    Regards,
    Dejan
    IJ wrote:
    edocs (http://e-docs.bea.com/wls/docs70/oracle/trxjdbcx.html#1080746) states that,
    if using jDriver for Oracle/XA you can not set the transaction isolation level
    for a
    transaction and that 'Transactions use the transaction isolation level set on
    the connection
    or the default transaction isolation level for the database'. Does this mean that
    you shouldn't try to set it programatically (fair enough) or that you can't set
    it in the weblogic deployment descriptor either? Also anybody got any idea what
    the default is likely to be if you are using
    an Oracle 9iR2 database?

  • Isolation Level for Transaction

    Hi
    Under the Advanced Mode in JDBC Adapter, there is an option " Isolation Level For Transaction ". I see two alternatives there, " Serializable " and " Repeatable Load ". Which one should we select and when do we select it ?
    Radhika

    Hi Radhika,
    Check below documentation..
    http://help.sap.com/saphelp_nw70/helpdata/en/22/b4d13b633f7748b4d34f3191529946/frameset.htm
    Regards,
    Swetha.

  • Multiple submits and Transaction setting and isolation level ????

    From a Struts JSP,
    I submit the form n times.
    I have a session facade in place. The corresponding function has trnsaction attribute as "Required" and the isolation level as "serializable"
    As a business rule the record cannot be inserted more than once.
    But it is......
    The Facade calls the Controller which in turn calls the VOA which calls DAO.
    There is a find method which looks for that unique id if it exists it throws an Validation exception.
    There are two scenes:
    -----If I open two IE and submit the form it throws validation exception
    -----If I click on submit more than once from the same IE it inserts as many records.
    Can any one please put some light????
    But the inserts is happening

    Could you make the picture more clear, probably with some code snippets where the actual database handshake is taking place?
    Also whether the business rule is a part of database constraints or is it done at the application level. From your description it seems that it is being done at the application level. Check if the find method check is getting executed each time, or is it being bypassed under certain conditions.

  • Setting the Isolation Level to Read Uncommitted

    Hello All,
    We are using BO XI r3 and SQL Server 2008. I would like to change the isolation level of the connection to read uncommitted. There are 2 options that i could by Googling..
    1. Making changes in the SBO file... this didnt work
    2. Making changes in the connectinit... even this didnt work
    i am not sure if there is anything else to done...  but i tried quering a table with a lock, the report got stuck so i am guessing that the settings didnt work

    Hi
    this is the only method for changing the transaction isolation level.
    Locate the path to your odbc.sbo file
    Click the connection in UDT and when server responds Click the Details button
    scroll down to the sbo line
    That is the file location of your sbo file (this will be the same on client and server)
    This change needs to be done, for client and servers both
    The isolation can only be set for the global connection.  Not per universe.
    Locate the file and make a backup before making any changes
    Find the Tag
    <DataBase Active="Yes" Name="MS SQL Server 2008">
    Below that tag should be a "Force SQLExecute" Parameter
    Like This
    <Parameter Name="Force SQLExecute">Procedures</Parameter>
    ADD this line
    <Parameter Name="Transaction Isolation Level">READ_UNCOMMITTED</Parameter>
    Save the odbc.sbo
    After client and server are changed
    Restart SIA
    Run the webi document again.
    Locations of the sbo file:
    R2: <Installation Directory>:\Program Files\Business Objects\BusinessObjects Enterprise 11.5\win32_x86\dataAccess\connectionServer\rdbms
    R3: <Installation Directory>:\Program Files\Business Objects\BusinessObjects Enterprise 12.0\win32_x86\dataAccess\connectionServer\rdbms
    BI4: <Installation Directory>:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\dataAccess\connectionServer\rdbms
    To make these changes effect, you have to restart ‘CMS server’, ‘the Connection Servers’, ‘Webi Report Server’ from ‘Central Configuration Manager’ (CCM).
    Information is available in the Data Access guide
    Jacqueline

  • How to define TX_SERIALIZABLE isolation level for a CMP EJB

    Hi JDev Team,
    I have created a portable Primary Key Generator realized as a CMP Entity Bean which
    has a method getNEXTID().
    This method returns a PK from a table
    and increments it by one.
    My question is:
    How can I set the transaction isolation level of getNEXTID() to TX_SERIALIZABLE in order to avoid phantom and dirty read problems?
    Best Regards,
    Stoyan K.

    Assuming you are using the bc4j cmp implementation, the default for isolation level is TX_READ_COMMITTED so I don't think you run the risk of phantom or dirty read.
    Unfortnately as of now this property cannot be specified declaratively.
    It looks like you want to run the getNEXTID() with the RequiredNew transaction attribute.
    null

  • How to set isolation level for BMP

    Hi.
    We're trying to avoid the ORA-08177 by setting the isolation level in the weblogic-ejb-jar.xml
    to READ_COMMITED
    Still (looking in the jdbc.log) it seems that weblogic set the transaction isolation
    level to SERIALIZABLE
    The xml :
    <weblogic-enterprise-bean>
    <ejb-name>Account</ejb-name>
    <caching-descriptor>
    <max-beans-in-cache>100</max-beans-in-cache>
    <idle-timeout-seconds>600</idle-timeout-seconds>
    <cache-strategy>Read-Write</cache-strategy>
    </caching-descriptor>
    <persistence-descriptor>
    <delay-updates-until-end-of-tx>true</delay-updates-until-end-of-tx>
    <finders-call-ejbload>false</finders-call-ejbload>
    </persistence-descriptor>
    <clustering-descriptor>
    <home-is-clusterable>false</home-is-clusterable>
    <home-load-algorithm>round-robin</home-load-algorithm>
    </clustering-descriptor>
    <enable-call-by-reference>false</enable-call-by-reference>
    <jndi-name>Account</jndi-name>
    <transaction-isolation>
         <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
    <method><ejb-name>Account</ejb-name><method-name>*</method-name></method>
    </transaction-isolation>
    </weblogic-enterprise-bean>
    Regards

    When I marked all the beans with READ_COMMITED it works.

  • Setting Transaction isolation level when I'm not in an EJB

              I have a Message Driven Bean (MDB) that is container managed, and its transaction
              isolation is set to TRANSACTION_READ_COMMITTED in weblogic-ejb-jar.xml and that
              seems to work fine. If I look at an entity bean in onMessage which is updated/commited
              outside the transaction I can see the updates no problem.
              Now the problem is this.. inside the onMessage method, the MDB creates a new
              instance of a class. This class starts up its own UserTransaction (using (UserTransaction)new
              InitialContext().lookup("javax.transaction.UserTransaction")) and goes into a
              loop working away. Inside the loop it is inspecting a value on an entity bean.
              The classs never sees any updates to this bean which are made outside this new
              UserTransaction.
              It looks to me that the UserTransaction that the class is getting has a different
              isolation level (serialized?). Is there a way to set the isolation level for
              a UserTransaction?
              Any help would be great!
              lance
              

              Just a follow up, I think the isolation level is perhaps being set to REPEATABLE_READ,
              since that is what seems to be happening. The value from the first read is maintained
              through subsequent reads in the same transaction.
              lance
              "Lance" <[email protected]> wrote:
              >
              >I have a Message Driven Bean (MDB) that is container managed, and its
              >transaction
              >isolation is set to TRANSACTION_READ_COMMITTED in weblogic-ejb-jar.xml
              >and that
              >seems to work fine. If I look at an entity bean in onMessage which is
              >updated/commited
              >outside the transaction I can see the updates no problem.
              >
              >Now the problem is this.. inside the onMessage method, the MDB creates
              >a new
              >instance of a class. This class starts up its own UserTransaction (using
              >(UserTransaction)new
              >InitialContext().lookup("javax.transaction.UserTransaction")) and goes
              >into a
              >loop working away. Inside the loop it is inspecting a value on an entity
              >bean.
              > The classs never sees any updates to this bean which are made outside
              >this new
              >UserTransaction.
              >
              >It looks to me that the UserTransaction that the class is getting has
              >a different
              >isolation level (serialized?). Is there a way to set the isolation level
              >for
              >a UserTransaction?
              >
              >Any help would be great!
              >
              >lance
              

  • Setting transaction isolation level in Weblogic 5.1

              Hi,
              I'm using Weblogic server5.1 and i'm trying to set the isolation level on one
              of my session bean. Below is the code :
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>chargeMgr</ejb-name>
              <jndi-name>chargeMgr</jndi-name>
              <transaction-isolation>
              <isolation-level>Serializable</isolation-level>
              <method>
              <ejb-name>chargeMgr</ejb-name>
              <method-intf>Remote</method-intf>
              <method-name>*</method-name>
              </method>
              </transaction-isolation>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              I have checked the syntax against the weblogic documentation.
              However, when i try to jar the beans up into the jar file (weblogic.ejbc), it
              give me the following error :
              org.xml.sax.SAXParseException: Element "weblogic-enterprise-bean" allows no further
              input; "transaction-isolation" is not allowed.
              Can anyone help?
              Regards.
              

    yes, only in weblogic-ejb-jar.xml , and you can see that from the DTD
              source.
              thanks
              Yu
              "cw lee" <[email protected]> wrote in message
              news:[email protected]...
              >
              > thanks for ur advice.
              >
              > one thing i forgot to mention is that the isolation-level was specified in
              weblogic-ejb-jar.xml.
              > Do u mean that it must be placed in weblogic-cmp-rdbms-jar.xml and not
              weblogic-ejb-jar.xml
              > ?
              >
              > Are the codes u suggested to be in weblogic-ejb-jar.xml or
              weblogic-cmp-rdbms-jar.xml
              > ?
              >
              > Regards.
              >
              >
              >
              > "Yu Tian" <[email protected]> wrote:
              > >the right name for Seriealizable should be: TRANSACTION_SERIALIZABLE.
              > >so the
              > >DD looks like:
              > >
              > ><?xml version="1.0"?>
              > >
              > ><!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic
              > >5.1.0
              > >EJB//EN' 'http://www.bea.com/servers/wls510/dtd/weblogic-ejb-jar.dtd'>
              > >
              > ><weblogic-ejb-jar>
              > > <weblogic-enterprise-bean>
              > > <ejb-name>containerManaged</ejb-name>
              > > <caching-descriptor>
              > > <max-beans-in-cache>1000</max-beans-in-cache>
              > > </caching-descriptor>
              > > <persistence-descriptor>
              > > <persistence-type>
              > > <type-identifier>WebLogic_CMP_RDBMS</type-identifier>
              > > <type-version>5.1.0</type-version>
              > > <type-storage>META-INF/weblogic-cmp-rdbms-jar.xml</type-storage>
              > > </persistence-type>
              > > <persistence-use>
              > > <type-identifier>WebLogic_CMP_RDBMS</type-identifier>
              > > <type-version>5.1.0</type-version>
              > > </persistence-use>
              > > </persistence-descriptor>
              > > <jndi-name>containerManaged.AccountHome</jndi-name>
              > > <transaction-isolation>
              > > <isolation-level>TRANSACTION_SERIALIZABLE</isolation-level>
              > > <method>
              > > <ejb-name>containerManaged</ejb-name>
              > > <method-name>*</method-name>
              > > </method>
              > > </transaction-isolation>
              > > </weblogic-enterprise-bean>
              > > </weblogic-ejb-jar>
              > >
              > >Thanks
              > >
              > >Yu
              > >
              > >
              > >"cw lee" <[email protected]> wrote in message
              > >news:[email protected]...
              > >>
              > >> Hi,
              > >>
              > >> I'm using Weblogic server5.1 and i'm trying to set the isolation level
              > >on
              > >one
              > >> of my session bean. Below is the code :
              > >>
              > >> <weblogic-ejb-jar>
              > >> <weblogic-enterprise-bean>
              > >> <ejb-name>chargeMgr</ejb-name>
              > >> <jndi-name>chargeMgr</jndi-name>
              > >> <transaction-isolation>
              > >> <isolation-level>Serializable</isolation-level>
              > >> <method>
              > >> <ejb-name>chargeMgr</ejb-name>
              > >> <method-intf>Remote</method-intf>
              > >> <method-name>*</method-name>
              > >> </method>
              > >> </transaction-isolation>
              > >> </weblogic-enterprise-bean>
              > >> </weblogic-ejb-jar>
              > >>
              > >> I have checked the syntax against the weblogic documentation.
              > >> However, when i try to jar the beans up into the jar file
              (weblogic.ejbc),
              > >it
              > >> give me the following error :
              > >>
              > >> org.xml.sax.SAXParseException: Element "weblogic-enterprise-bean"
              allows
              > >no further
              > >> input; "transaction-isolation" is not allowed.
              > >>
              > >> Can anyone help?
              > >>
              > >> Regards.
              > >>
              > >
              > >
              >
              

  • Setting transaction isolation levels in WAS5

    I think I'm missing something pretty easy. How can I set the isolation
    levels for the containter managed transactions on my beans?
    Specifically, I want to set soem lookup methods on my Sessions beans
    to TRANSACTION_REPEATABLE_READ. I've already put the
    container-transaction blocks in my ejb-jar.xml
    Does Websphere 5 have something akin to WebLogic's
    weblogic-ejb-jar.xml where you can set additional parameters like
    this? Do I have to use a tool like WSAD to specify this? The AAT
    doesn't seem to have this option.
    Thanks,
    James Lynn

    Hi Slava, Ryan,
    We haven't looked at 8.1 yet since our release cycle wouldn't allow us
    to move to 8.1 until at least June anyway, but even if the problems was
    fixed there it took BEA support more than 6 months (I opened the case on
    Sep 23 2002 and only this week I got the patch that I haven't even tried
    to test to see if it works) to issue a patch for such a small problem.
    The server would just check if the Oracle XA driver was being used and
    no matter what version would just throw an exception if you try to set
    the transaction isolation level saying that the feature in the Oracle
    8.1.7 driver was broken... (although you might be using 9.x or even a
    pre-8.1.7 driver)...
    So this is about it.
    And Slava, I've tried pushing a case harder only to end up with BEA
    support trying to convince me that I was misinterpreting the JDBC spec
    when it was not true, so I just gave up. The main goal of BEA support in
    all of our experience has been that they don't try to solve the cases
    but close them.
    That's my and some of my colleagues personal views anyway, you don't
    have to share them.
    Regards,
    Dejan
    Slava Imeshev wrote:
    Hi Deyan,
    Sorry for the delay. Could you give us more details about CR090104?
    I've got some feedback in XA area, not sure if it was a related case.
    Also, I've never had any problems with weblogic CCE, so you may want
    to push your case a little harder.
    As per the bold statement - the initial question was about functionality
    available in weblogic but not available in websphere - it can't be more
    bold :)
    Regards,
    Slava Imeshev
    "Deyan D. Bektchiev" <[email protected]> wrote in message
    news:[email protected]...
    This is a very bold statement Slava, considering that with Oracle XA
    driver you cannot even set the transaction isolation level because of a
    Weblogic bug (CR090104 that has been open for more than 6 months
    already)...
    Dejan
    Slava Imeshev wrote:
    Hi James,
    "James F'jord Lynn" <[email protected]> wrote in message
    news:[email protected]...
    I think I'm missing something pretty easy. How can I set the isolation
    levels for the containter managed transactions on my beans?
    Specifically, I want to set soem lookup methods on my Sessions beans
    to TRANSACTION_REPEATABLE_READ. I've already put the
    container-transaction blocks in my ejb-jar.xml
    Does Websphere 5 have something akin to WebLogic's
    weblogic-ejb-jar.xml where you can set additional parameters like
    this? Do I have to use a tool like WSAD to specify this? The AAT
    doesn't seem to have this option.
    My guess here is that it's a signal that this is a last chance
    for you to abandon WebSphere and return back to WebLogic's
    safe harbor.
    Regards,
    Slava Imeshev

  • How to set Transaction isolation level in Weblogic 11g

    How do I set the transaction isolation level in Weblogic?
    Some references that I found suggest that I have to explicitely state the isolation level in the weblogic-ejb-jar.xml per ejb. If I am using EJB 3.0 why would I need to do that?
    Can I set this up as a property in the JDBC datasource setup?
    Other application servers like Websphere actually allows for this. Can this be done in Weblogic?
    Currently I get the following message if I don't set the isolation level:
    Transaction attribute: TX_NOT_SUPPORTED Isolation Level: No Isolation Level Set Tx Timeout: 30000
    What seems to be happening is that one update of my transaction is getting rolled back and other consequent calls are failing due to foreign key issues due to the first rollback.
    I think the issue is related to the isolation level or the transaction time out being too low.
    Any ideas?
    BTW: I am using openjpa and using a MS SQLServer. Not sure if that helps the discussion.
    Thanks
    Edited by: rrivera on Jun 2, 2010 9:18 AM

    How do I set the transaction isolation level in Weblogic?
    Some references that I found suggest that I have to explicitely state the isolation level in the weblogic-ejb-jar.xml per ejb. If I am using EJB 3.0 why would I need to do that?
    Can I set this up as a property in the JDBC datasource setup?
    Other application servers like Websphere actually allows for this. Can this be done in Weblogic?
    Currently I get the following message if I don't set the isolation level:
    Transaction attribute: TX_NOT_SUPPORTED Isolation Level: No Isolation Level Set Tx Timeout: 30000
    What seems to be happening is that one update of my transaction is getting rolled back and other consequent calls are failing due to foreign key issues due to the first rollback.
    I think the issue is related to the isolation level or the transaction time out being too low.
    Any ideas?
    BTW: I am using openjpa and using a MS SQLServer. Not sure if that helps the discussion.
    Thanks
    Edited by: rrivera on Jun 2, 2010 9:18 AM

  • Set isolation level in EJB 2.0

    how can i set isolation level to a transaction in EJB 2.0.
    If anybody can give example code much appriciated

    For 5.1, look at:
              http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_environment.html#107261
              7
              http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_reference.html#1061916
              "marshalli" <[email protected]> wrote in message
              news:3a59546d$[email protected]..
              >
              > How to set the isolation level(Container Manager or Bean Manager) in EJB.
              Thanks
              >
              >
              

Maybe you are looking for

  • Best practice to Change Dial plan?

    Hi, Customer has made plenty of misdialed 911 calls so they want to change the dial plan. They have CUCM, CUC and UCCX .. I will try to suggest putting a delay for 3 sec or so and blocking 911! or 911!# translation pattern .. but in case if they do w

  • How to get transacted session in direct mode with jmsra adapter

    Hi, I use MQ 4.4u1 release with GF in EMBEDDED mode. I configured several connection factories with NoTransaction/LocalTransaction/XATransaction support. In my app I get a connection factory from JNDI tree, create connection/session/producer and send

  • Thunderbird do not send my e-mail

    thunderbird do not send my e - mail but recive (on my mail address [email protected]) with regularity the mail or answers of my correspondents.

  • Weblogs related to Ruby and SAP

    This thread is dedicated to publishing new weblogs. Do not append any comments onto this thread! Only if you have written a weblog, then append a small description with the link here. For everyone else that are interested, press the "Watch this Topic

  • Problem in Simple file to file scenario

    Hello, I am new to SAP PI 7.3. I am doing a simple file to file scenario. The source file contains key,name,id,gender,role & location field. I have done a simple mapping to create the same file in the target side. I have done all the configuration in