websphere lesson #154

when in doubt, enable traces

Advertisements

Container-Managed Transaction Demarcation for Session and Entity Beans

ejb-3_0-fr-spec-ejbcore

13.6.2 Container-Managed Transaction Demarcation for Session and Entity Beans

13.6.2.1 NOT_SUPPORTED

The container invokes an enterprise bean method whose transaction attribute is set to the NOT_SUPPORTED value with an unspecified transaction context.

If a client calls with a transaction context, the container suspends the association of the transaction context with the current thread before invoking the enterprise bean’s business method.

The container resumes the suspended association when the business method has completed. The suspended transaction context of the client is not passed to the resource managers or other enterprise bean objects that are invoked from the business method. If the business method invokes other enterprise beans, the container passes no transaction context with the invocation.

Refer to Subsection 13.6.5 for more details of how the container can implement this case.

13.6.2.2 REQUIRED

The container must invoke an enterprise bean method whose transaction attribute is set to the REQUIRED value with a valid transaction context.

If a client invokes the enterprise bean’s method while the client is associated with a transaction context, the container invokes the enterprise bean’s method in the client’s transaction context.

If the client invokes the enterprise bean’s method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method. The container automatically enlists all the resource managers accessed by the business method with the transaction. If the business method invokes other enterprise beans, the container passes the transaction context with the invocation. The container attempts to commit the transaction when the business method has completed. The container performs the commit protocol before the method result is sent to the client.

13.6.2.3 SUPPORTS

The container invokes an enterprise bean method whose transaction attribute is set to SUPPORTS as follows.

  • If the client calls with a transaction context, the container performs the same steps as described in the REQUIRED case.
  • If the client calls without a transaction context, the container performs the same steps as described in the NOT_SUPPORTED case.
  • The SUPPORTS transaction attribute must be used with caution. This is because of the different transactional semantics provided by the two possible modes of execution. Only the enterprise beans that will execute correctly in both modes should use the SUPPORTS transaction attribute.

    13.6.2.4 REQUIRES_NEW

    The container must invoke an enterprise bean method whose transaction attribute is set to REQUIRES_NEW with a new transaction context.

    If the client invokes the enterprise bean’s method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method. The container automatically enlists all the resource managers accessed by the business method with the transaction. If the business method invokes other enterprise beans, the container passes the transaction context with the invocation. The container attempts to commit the transaction when the business method has completed. The container performs the commit protocol before the method result is sent to the client.

    If a client calls with a transaction context, the container suspends the association of the transaction context with the current thread before starting the new transaction and invoking the business method. The container resumes the suspended transaction association after the business method and the new transaction have been completed.

    13.6.2.5 MANDATORY

    The container must invoke an enterprise bean method whose transaction attribute is set to MANDATORY in a client’s transaction context. The client is required to call with a transaction context.

  • If the client calls with a transaction context, the container performs the same steps as described in the REQUIRED case.
  • If the client calls without a transaction context, the container throws the javax.ejb.EJBTransactionRequiredException[69]. If the EJB 2.1 client view is used, the container throws the javax.transaction.TransactionRequiredException exception if the client is a remote client, or the javax.ejb.TransactionRequiredLocalException if the client is a local client.
  • 13.6.2.6 NEVER

    The container invokes an enterprise bean method whose transaction attribute is set to NEVER without a transaction context defined by the EJB specification. The client is required to call without a transaction context.

  • If the client calls with a transaction context, the container throws the javax.ejb.EJBException[ 70]. If the EJB 2.1 client view is used, the container throws the java.rmi.RemoteException exception if the client is a remote client, or the javax.ejb.EJBException if the client is a local client.
  • If the client calls without a transaction context, the container performs the same steps as described in the NOT_SUPPORTED case.
  • isolation levels

    Oracle RDB uses a locking mechanism for controlling concurrency and enforcing logical and physical integrity of the database. The strategy for locking objects is as follows:

    * Lock the object
    * Perform the required work on the object
    * Unlock the object at a later time, most likely at the end of the Transaction

    Among lockable objects the following hierarchy is found:

    * Database
    * Table
    * Page
    * Row
    * Index node

    Oracle RDB implements a dedicated logic that chooses the appropriate object and adjusts the lock granularity. It selects a suitable lock object and level which are based on the operation being performed in a given context. All this is aimed at minimizing potential lock conflicts.

    Note that the locking scope is normally associated with a transaction. The SET TRANSACTION syntax contains elements for controlling the LOCKING applied:

    * READ/WRITE
    * WAIT [x]/NOWAIT

    Nevertheless Oracle RDB locking policy is rather strict. Lock conflicts are a matter of routine in a database that serves multiple users concurrently. A user can be a ‘Blocker’, while holding a locked resource required by others, or ‘Blocked By’, while waiting for a resource locked by others to be released or ‘Both’.

    Circular lock conflicts can lead to deadlock situations where User A locks Resource 1 and waits for Resource 2, which is locked by User B who is waiting for Resource 1.

    The Oracle RDB data source driver is aware of Oracle RDB potential locking conflicts and provides certain built-in relief measures:

    * The default transaction WAIT parameter is 0. This translates to NOWAIT, which actually means that a default transaction initiated by the Oracle RDB data source will not be blocked. Instead it will inform of a lock conflict if one is encountered.
    * The default proposed isolation level is READ COMITTED which reduces lock contention and increases the degree of concurrency. Note that this affects ‘pure’ transactional integrity, since data committed by others is visible in your transaction.
    * The Oracle RDB data source maintains dual (multiple) connections to the database. This notion is based on the fact that when snapshots are enabled for a database (the default), READ ONLY transactions do not lock the rows they read. Data is read from the snapshot maintained by Oracle RDB. Therefore the Oracle RDB data source driver normally holds two connections to the database. The first, denoted as NAV in the data source driver’s log, is used for WRITE transactions, which are subject to LOCK conflicts. The second, denoted as NAVREAD, serves the READ transactions. This notion of duplicating connections is also extended to separating DDL and stored procedure locking activities from the main data source driver’s course, which is READ/WRITE operations.
    * The Oracle RDB data source provides explicit control on elements that affect locking along the transaction. This is carried out by assigning appropriate values to configurable parameters, as described above. In particular, ISOLATION LEVEL can be set explicitly both for READ and WRITE transactions as follows:

    – readCommitted: Allows your transaction to see all data committed by other transactions.

    – repeatableRead: Guarantees that if you execute the same query again, your program receives the same rows it read the first time. However, you may also see rows inserted and committed by other transactions (known as Phantoms).

    – serializable: Guarantees that the operations of concurrently executed transactions are not affected by any other transaction.

    Serializable

    from ask tom

    The ANSI/ISO SQL92 standard adds to the concurrency control mix as well. In this standard, they define four levels of transaction isolation with different possible outcomes for the same transaction mixes. That is, the same work performed in the same fashion with the same inputs, may result in different answers given your isolation level. These isolation levels are defined in terms of three ‘phenomena’ that are either permitted or not at a given level. These phenomena are:

    * Dirty read : The meaning of this is as bad as it sounds. You are permitted to read uncommitted ‘dirty’ data. This is the effect you would achieve by just opening an OS file someone else is writing, and reading whatever data happened to be there. Data integrity is compromised, foreign keys violated, unique constraints ignored.

    * Non-repeatable read : This simply means that if you read a row at time T1, and attempt to re-read that row at time T2, the row may have changed. It may have disappeared, it may have been updated, and so on.

    * Phantom read : This means that if you executed a query at time T1, and re-execute it at time T2, additional rows may have been added to the database, which affects your results. This differs from the non-repeatable read in that in this case, data you already read has not been changed but rather that more data satisfies your query criteria than before.

    SQL92 takes these three phenomena and creates four isolation levels based on the existence, or lack thereof, of the above phenomena. They are:

    Isolation Level Dirty Read Non-Repeatable Read Phantom Read
    Read Uncommitted Permitted Permitted Permitted
    Read Committed   Permitted Permitted
    Repeatable Read     Permitted
    Serializable      

    Oracle supports explicitly two of the above isolation levels as they are defined ? read committed and serializable. This doesn’t tell the whole story however. The SQL92 standard was attempting to set up isolation levels that would permit various degrees of consistency for queries performed in each level. Repeatable read is the isolation level they claim you must be at to get a read consistent result from a query. Read committed does not give you consistent results. Read uncommitted is the level to use to get non-blocking reads.

    So, serializable gives you the ability to prevent “phantom reads” — a really really repeatable read if you will. To paraphrase:

    A serializable transaction operates in an environment that makes it appear as if there are no other users modifying data in the database, the database will be “frozen” at the point in time your query began. Your transaction sees the database consistently, at a single point in time. Side effects (changes) made by other transactions are not visible to it, regardless of how long it has been running.
    that is what is given beyond read committed. In a serializable transaction if you do the following:

    t1       select count(*) from b -- returns "0"
    t2                                                   insert into b values(1);
    t3                                                   commit;
    t4                                                   select count(*) from b --
                                                             returns "1"
    t5       select count(*) from b -- returns "0"
    t6       commit;
    t7       select count(*) from b -- returns "1"
    
    

    Using read committed, the query at time t5 would return 1, not 0. You get a “phantom read”


    This is generally considered the most restrictive level of transaction isolation, but provides the highest degree of isolation. A serializable transaction operates in an environment that makes it appear as if there are no other users modifying data in the database, the database will be “frozen” at the point in time your query began. Your transaction sees the database consistently, at a single point in time. Side effects (changes) made by other transactions are not visible to it, regardless of how long it has been running. Serializable does not mean that all transactions executed by the users are the same as if they were executed one right after another in a serial fashion. It does not imply that there is some serial ordering of the transactions that would result in the same outcome. This last point is a frequently misunderstood concept and a small demonstration will clear it up. The following table represents two sessions performing work over time. The database tables A and B referenced in the example start out empty and are created as such:

    tkyte@TKYTE816> create table a ( x int );
    Table created.
    
    tkyte@TKYTE816> create table b ( x int );
    Table created.
    
    Time    Session 1 Executes    Session 2 Executes
    0:00    Alter session set isolation_level=serializable;
    0:01                            Alter session set isolation_level=serializable;
    0:02    Insert into a select count(*) from B;
    0:03                            Insert into b select count(*) from A;
    0:04    Commit;
    0:05                            Commit;
    

    Now, when this is all said and done – A and B will each have a row with the value of zero in it. If there was some “serial” ordering of the transactions – we could not possibly have both tables containing the value zero in them. If Session 1 executed before Session 2 ? then table B would have a count of 1. If Session 2 executed before Session 1 ? then table A would have a count of 1. Both tables however will have a count of ZERO. They just executed as if they were the only transaction in the database at that point in time. No matter how many times Session 1 queried table B – the count would be the count that was committed in the database at time 0:00. Likewise, no matter how many times Session 2 queries table A – it will be the same as it was at time 0:01.

    So, what I was trying to demonstrate is what serializable means — in short:

    A serializable transaction operates in an environment that makes it appear as if there are no other users modifying data in the database, the database will be “frozen” at the point in time your query began. Your transaction sees the database consistently, at a single point in time. Side effects (changes) made by other transactions are not visible to it, regardless of how long it has been running.

    13 Data Concurrency and Consistency

    post blog remotely with wordpress-library

    wordpress-library

    # http://code.google.com/p/wordpress-library/source/checkout
    import wordpresslib
    import getopt
    import sys
    import re
    import random
    
    TITLE_RE = re.compile(r'title=(.*)',re.IGNORECASE)
    TAGS_RE = re.compile(r'tags=(.*)',re.IGNORECASE)
    
    def usage():
    	print "Usage: python " + sys.argv[0] + " -w wordpress_url -u user -p password [-t title] -f file"
    
    def main():
    	try:
    		opts, args = getopt.getopt(sys.argv[1:], "w:u:p:t:f:")
    	except getopt.GetoptError, err:
    		# print help information and exit:
    		print str(err) # will print something like "option -a not recognized"
    		usage()
    		sys.exit(2)
    
    	user = passwd = title = file = url = tags = None
    
    	for o,a in opts:
    		if o == "-u":
    			user = a
    		elif o == "-p":
    			passwd = a
    		elif o == "-t":
    			title = a
    		elif o == "-f":
    			file = a
    		elif o == "-w":
    			url = a
    		else:
    			assert False, ("unhandled option '%s'" % o)
    
    	if not user or not passwd or not url or not file:
    		usage()
    		sys.exit(3)
    
    	fh = open(file)
    	flines = fh.readlines()
    	fh.close()
    
    	if not flines:
    		print 'error: nothing to post'
    		sys.exit(4)
    
    	match = TITLE_RE.search(flines[0])
    	if match:
    		title = match.group(1)
    		flines = flines[1:] # skip line
    	
    	match = TAGS_RE.search(flines[0])
    	if match:
    		tags = match.group(1)
    		flines = flines[1:]
    	
    	if not flines:
    		print 'error: nothing post body found'
    		sys.exit(5)
    
    	body = ''.join(flines)
    
    	wp = wordpresslib.WordPressClient(url, user, passwd)
    
    	# select blog id
    	wp.selectBlog(0)
    
    	post = wordpresslib.WordPressPost()
    	post.title = title or ('untitled-' + str(random.randint(500, 50001)))
    	post.tags = tags or ''
    	post.description = body 
    	#post.categories = (wp.getCategoryIdFromName('Python'),)
    
    	# pubblish post
    	idNewPost = wp.newPost(post, True) # False
    
    	print 'posting successful', idNewPost
    
    if __name__ == '__main__':
      main()
    
    

    sample blog post


    title=Test1
    tags=testing,xmlrpc,wordpresslib

    <span style="background-color:yellow">testing 123</span>
    <div style="margin-left:10%;margin-right:10%">hello again</div>
    <ol>
    <li>one</li>
    <li>two</li>
    </ol>
    <ui>
    <li>a point</li>
    <li>another point</li>
    </ui>
    <strong>very bold</strong>
    <span style=’color:red’>and this is red</span>
    and a table
    <table border="1" style="margin:2%">
    <tr>
    <td>col1</td>
    <td>col2</td>
    <td>col3</td>
    </tr>
    </table>

    <div>new line</div>


    editplus cliptext file for writing wordpress blog
    wordpress.ctl

    happey blogging with editplus

    Add Search to Internet Explorer context menu

    trying to add ‘Search’ menu item in context menu of Internet Explorer 7, so that if I select some text and right click, in the context menu there should be an item ‘Search’ that should open search result in new tab using search engine of your choice.

    Adding Entries to the Standard Context Menu

    /*
    to add Search in context menu, add following registry enrty
    [HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\MenuExt\&Search]
    "Context"=dword:00000031
    @="file://C:\\scripts\\ie-search.js "
    
    @ represents "Default" key
    */
    <SCRIPT LANGUAGE = "JScript">
    
    // Get the window object where the context menu was opened.
    var oWindow = window.external.menuArguments;
    
    // Get the document object exposed through oWindow.
    var oDocument = oWindow.document;
    
    // Get the selection from oDocument.
    // in oDocument.
    var oSelect = oDocument.selection;
    
    // Create a TextRange from oSelect.
    var oSelectRange = oSelect.createRange();
    
    // Get the text of the selection.
    var sNewText = oSelectRange.text;
    
    // If nothing was selected, insert some text.
    if (sNewText.length != 0){
    
    /***************************************
     top open in new tab I couldnt find any method
     supported for IE7, so make sure following
     setting is done.
    
     Tool -> Internet Options -> 
      General Tab
      look for "Change how webpages are displayed in tabs"
      click "Settings" button next to it
      look for "When a opo-up is encountered"
    	set "Always open pop-ups in a new tab"
    
     later on we didnt needed this as open batch file
     will open new url in new tab if IE is already open
     ***************************************/
    	
       // attempts to open search result in new tab
       //oWindow.open("http://www.google.com/search?q=" + sNewText,"_blank");
       //oWindow.navigate("http://www.google.com/search?q=" + sNewText,"_blank");
       //window.external.NavigateAndFind("http://www.google.com/search?q=" + sNewText, "", "_parent");
    
       //CScript.CreateObject( "WScript.Shell" ).Run("start " + "http://www.google.com/search?q=" + sNewText);
    
       // finally this works
       var oShell = new ActiveXObject("Shell.Application"); 
       oShell.ShellExecute("c:/temp/g.bat", sNewText);
    /*
            g.bat contains following--
    
    @start /MIN /B http://www.google.com/search?q=%1
    */
    
    /*
     Copy Enum BrowserNavConstants
         navOpenInNewWindow = 1
         navNoHistory = 2
         navNoReadFromCache = 4
         navNoWriteToCache = 8
         navAllowAutosearch = 16
         navBrowserBar = 32
         navHyperlink = 64
         navEnforceRestricted = 128
         navNewWindowsManaged = 256
         navUntrustedForDownload = 512
         navTrustedForActiveX = 1024
         navOpenInNewTab = 2048
         navOpenInBackgroundTab = 4096
         navKeepWordWheelText = 8192
         navVirtualTab = 16384
         navBlockRedirectsXDomain = 32768
         navOpenNewForegroundTab = 65536
     End Enum
    
     BrowserNavConstants Enumeration
     http://msdn.microsoft.com/en-us/library/dd565688.aspx
    
     Navigate2 - Navigate2 not available 
     http://msdn.microsoft.com/en-us/library/aa752094.aspx
    */
    
    }
    </SCRIPT>
    

    Local interfaces in same jvm but different EAR issue – Websphere

    from http://fixunix.com/websphere/344774-local-interfaces-same-jvm-but-different-ear-issue.html#post894504

    This issue is caused by the test.ejb.ProcessorLocalHome class being loaded by two different classloaders, one classloader for each EAR (which is the WAS default).

    The EJB spec itself is fairly silent on whether EJB local (pass-by-reference) interfaces may be used across Java EE applications (i.e. different EAR files). It says that the caller and callee must be in the same JVM, but is silent on the other aspects that factor into whether it will work or not. One aspect that Paul mentioned is that there’s no spec-defined way to look up a local interface within the global JNDI namespace; this means that the only way to get ahold of a local interface is through an ejb-local-ref element in the calling application, along with using an ejb-link element to point the local-ref at the target local interface. The syntax for ejb-link only allows for pointing at EJBs within the same EAR file as the caller, not across EAR files. WAS allows you to set an external EJB binding in the calling EAR using a global JNDI name (seemingly for the remote interface), but under the covers WAS modifies the data from the binding to get the local interface inste
    ad. This “modification” is hidden from the user and unfortunately has caused a fair amount of customer confusion when debugging.

    After getting past the naming issue, the next issue that commonly comes up is the ClassCastException. It’s not commonly understood that when two classloaders load the exact same Java .class file, objects created from the two classloaders are still NOT type-assignable to each other even though they implement the same class name (and even if they’re based on the same .class file). In this case the generated test.ejb.EJBLocalStatelessProcessHome_6f83b3f2 class DOES implement test.ejb.ProcessorLocalHome, but it implements the test.ejb.ProcessorLocalHome that was loaded by the other application’s classloader. Thus, when the calling app tries to assign the instance to a variable of test.ejb.ProcessorLocalHome, you get a ClassCastException.

    One way to prevent this is to use a remote interface. As Paul mentioned, there is optimization that happens when the caller and callee are in the same JVM, so it’s not as expensive as if they’re in separate JVMs. The ORB has classloader machinery that ensures the classes for the caller and callee are loaded using classloaders compatible with each side of the call.

    Option 2, including the ejb jar within the new ear, won’t solve the problem. Even though the classes will be available in both classloaders, the object passed by-reference from callee back to caller will still be instanciated using the other application’s classloader and will not be type-assignable. Same with Option 3.

    The 2nd way to make it work is to place the classes used by caller and callee in a “WAS shared library” and configure both applications to use that shared library. The subject of shared libraries and how to configure them is described in the WAS InfoCenter documentation…search on “shared library.”

    The 3rd way to make it work, which is the least desirable of the three, is to change the WAS server classloader policy to “one classloader per server.” The default, as I mentioned at the top, is “one classloader per application (EAR file).” Changing to one classloader per server ensures that everything gets loaded by the same classloader and is thus type-compatible, but deprives your applications of the isolation/security benefits that come from having each app in its own classloader.

    Randy

    another How Can i declare local-jndi-name in my ibm-ejb-jar-bnd.xmi

    and another Local EJB calls between separate ear/jar possible ?

    client inactivity timeout

    WebSphere Application Server

    http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-dist&topic=Transaction_service
    Specifies the maximum duration, in seconds, between transactional requests from a remote client. Any period of client inactivity that exceeds this timeout results in the transaction being rolled back in this application server.

    If you set this value to 0, there is no timeout limit.

    Data type | Integer
    Units     | Seconds
    Default   | 60
    Range     | 0 to 2147483647
    

    http://www14.software.ibm.com/webapp/wsbroker/redirect?version=compass&product=was-nd-dist&topic=tjta_settlog
    The number of seconds after which a client is considered inactive and the transaction service ends any transactions associated with that client. A value of 0 (zero) indicates that there is no timeout limit.

    http://www-01.ibm.com/support/docview.wss?uid=swg1PK07143
    Given the following topology:

       Server 1             Server 2
        EJB 1                EJB 2
    

    If EJB 1 makes a call to EJB 2, and EJB 2 returns correctly, but the transaction on EJB 1 lasts long enough to cause a client inactivity timeout on Server 2, Server 1 will not know until its transaction is finished running. If the transaction lasts a long time, the EJB on Server 1 could potentially run for 30 minutes or more and not realize it will have to perform a rollback, because of the client inactivity timeout.

    The operation is working as designed, but Server 1 should have some way of knowing that it will have to perform a rollback before it spends 30 minutes doing work that will just get rolled back anyway. Currently it cannot know.

    Local fix

    There are two options:

    1. Set the client inactivity timeout to a value long enough to avoid causing the rollback in the first place.

    2. Use an intermediary EJB on Server 1 that uses TX_REQUIRES_NEW or TX_NOT_SUPPORTED before it then forwards the request to Server 2. In this way, the transaction on Server 1 will be suspended before the client call to Server 2. When the transaction on Server 1 resumes, it will not care about keeping Server 2 in the loop and the timeout won’t occur because Server2 was never made a part of Server 1’s transaction.

    _____________________________________________________________________
    server1 client inactivity timeout is set to 60 secs
    server1 Total transaction lifetime timeout 120 secs

    server2 client inactivity timeout is set to 90 secs
    server2 Total transaction lifetime timeout 120 secs

    ejb1 deployed on server1
    ejb2 deployed on server2

    if ejb1 calls ejb2 (method ejb2_m1) and after the call ejb1 keep doing something else for more then 90 secs (server2 client inactivity timeout) and doesnt call anyother methods (including ejb2_m1) on ejb2 then ejb2 will detect client inacticity and rollback the transaction after 90 secs of completion of last call.

    so what the point of ‘client inactivity timeout’ and why it needed when ‘Total transaction lifetime timeout’ is there why not make it default 0.
    _____________________________________________________________________

    ****************************************************
    Total transaction lifetime timeout
    ****************************************************
    The default maximum time, in seconds, allowed for a transaction that is started on this server before the transaction service initiates timeout completion. Any transaction that does not begin completion processing before this timeout occurs is rolled back.

    ****************************************************
    Maximum transaction timeout
    ****************************************************
    Specifies, in seconds, the upper limit of the transaction timeout for transactions that run in this server. This value should be greater than or equal to the value specified for the total transaction timeout.

    This timeout constrains the upper limit of all other transaction timeouts. The following table shows how the different timeout settings apply to transactions running in the server.

    Transaction timeout settings.
    Timeout setting                    | Transactions affected
    -----------------------------------------------------------
    Maximum transaction timeout        | All transactions running in this server that are not affected by the total transaction lifetime timeout or an application component timeout. These transactions include transactions imported from outside this server, such as those imported from a client.
    Total transaction lifetime timeout | All transactions that originated in this server that are not affected by an application component timeout, in other words, the associated application component does not set its own timeout.
    Application component timeout      | Transactions that are specific to an application component. If the component is a container-managed bean, set this timeout in the deployment descriptor for the component. If the component is a bean-managed bean, set this timeout programmatically using the UserTransaction.setTransactionTimeout method.
    

    If you set a timeout to 0, that timeout does not apply, and is effectively disabled. If you set all timeouts to 0, transactions never time out.

    For example, consider the following timeout values:

    Maximum transaction timeout        360
    Total transaction lifetime timeout 240
    Application component timeout       60
    

    In this example, transactions that are specific to the application component time out after 60 seconds. Other local transactions time out after 240 seconds, and any transactions that are imported from outside this server time out after 360 seconds. If you then change the application component timeout to 500, application component transactions time out after 360 seconds, the value of the maximum transaction timeout. If you set the maximum transaction timeout to 0, application component transactions time out after 500 seconds. If you remove the application component timeout, application component transactions time out after 240 seconds.
    To determine the occurrence of a timeout quickly, and to prevent further resource locking, the application server prevents further transactional work on the transactional path where the timeout condition has taken place. This applies equally to attempting to perform work under the current transaction context and to attempting to perform work under a different transactional context.

    Data type | Integer
    -------------------
    Units     | Seconds
    Default   | 300
    Range     | 0 to 2 147 483 647
    Range     | 0 to 2 147 040