Strange behavior  in entity bean : get Timestamp

Hello:
I'm working with SUNONE 7 AppServer , over SunOS 5.9
I've a strange behavior with entity's get methods which return Timestamp value.
For example, I've got
Timestamp date;
If I do
entity.setF(date) , ( date is a Timestamp with value "12/12/2005 12:30:00" )
all works right, and in database is wrote right ( "12/12/2005 12:30:00" )
But , if I do
date = entity.getF()
the, date variable has the value "12/12/2005 00:00:00"
So, in get method is lost the time value of a Timestamp data
Could be a code bug in my source , but if I use Jboss AS over Windows XP , all work right ( set and get methods ). The database is the same one ( Oracle 9i )

Well, I found the solution.
The problem was the ojdbc14.jar driver, which made wrong schema files.
Exactly, with the bad ojdbc14.jar, generated this entry
<_type>91</_type>
when the right one for date types ( Timestamp ) is
<_type>93</_type>
I dont know why the new ojdbc14.jar works fine, but I paste its size
good ojdbc14.jar : 1181679 bytes

Similar Messages

  • Strange behavior with entity beans and servlets in a cluster

    We have 2 WebLogic 4.5.1 servers in a cluster with none of the Service
              Packs installed. When a client uses the deployed entity beans or
              servlets they work every other time. The times they do not work nothing
              happens. No exceptions, no responses to the client ( i.e. HTTP 404s ),
              nothing. I suspect something in the cluster setup since we do not have
              these same problems on non-clustered entity beans or servlets. We have
              made sure all the entity beans have the Shared Database flag set on and
              added the delayUpdatesUntilEndOfTx false to the enviroment of the DD.
              That didn't fix the problem. Any ideas?
              Thanks in advance,
              Dallas Dempsey
              DEM - Houston, TX
              

    Do you have log files?
              - Prasad
              Chris Dempsey wrote:
              > We have 2 WebLogic 4.5.1 servers in a cluster with none of the Service
              > Packs installed. When a client uses the deployed entity beans or
              > servlets they work every other time. The times they do not work nothing
              > happens. No exceptions, no responses to the client ( i.e. HTTP 404s ),
              > nothing. I suspect something in the cluster setup since we do not have
              > these same problems on non-clustered entity beans or servlets. We have
              > made sure all the entity beans have the Shared Database flag set on and
              > added the delayUpdatesUntilEndOfTx false to the enviroment of the DD.
              > That didn't fix the problem. Any ideas?
              >
              > Thanks in advance,
              > Dallas Dempsey
              > DEM - Houston, TX
              

  • Entity Beans not getting garbage collected

    Hi,
    I am developing an application that is using EJBs utilizing several common design patterns (i.e. Session Facade, DAO, and Fast Lane Reader). All of the patterns used have come from books by Sun Microsystems Press.
    As I have understood the pattern, the Session Facade pattern uses Stateless Session Beans (SLSB) to implement a desired functionality and accesses the entity beans locally. The results from the entity beans are placed into Value Objects and passed back to the client separating any direct access with the entity beans from the client. In my case, I am using BMP for my entity beans.
    The problem I am seeing with Optimizeit is that none of my entity beans are getting garbage collected despite no references to them. The SLSB creates what entities it needs to perform a task at the local level, puts the data into a value object and goes out of scope.
    Shouldn't the entity beans get removed if the object that references them has gone away or am I missing something?
    Is there a proper way to set an entity bean (or any EJB for that matter) for garbage collection.
    thanks in advance for any help...

    You might even discover that entity beans can get created even before you use them.
    Your application server creates "pools" of bean instances that it can use when it needs to. It is part of this role, and is done in order to optimize performances.
    You cannot force them to be garbage collected. Even if you stop referencing them, the app server will.
    When your create references to a bean, it (usually) won't create an instance. It will take an existing one, and load data into it, using ejbCreate or ejbActivate.
    Hope this helps.
    /Stephane

  • Entity bean - Unknow primary key problem

    Hi,
    We are using entity bean with unknown primary key option to generate the primary key automatically. It works for all the tables except one table. What we observe is, auto generated primary key is less than the max value in the table and is clashing with one existing record. Any thoughts on what could be wrong?
    Your help is highly appreciated.
    Regards,
    Chandra
    Edited by: Chandrashekhar Singh on Mar 3, 2008 6:39 PM

    Hi,
    I think Vladimir's answer can help you.
    [Entity bean - getting Duplicate Key Exception on ejbCreate;
    Regards
    Pavel

  • 60 Second Delays in Client Getting Entity Bean (after finder method)

    I am running WLS5.1 with SP10. I have a stateless EJB that gets a
    read-write BMP entity EJB. My test client that executes the stateless
    session bean periodically encounters long delays (60 seconds or more)
    when acquiring the entity bean using its finder method. Logging shows
    the finder method is executing properly, and typically takes 180 ms to
    locate the entity bean; however, from the stateless session beans side,
    it appears to take 60 seconds. The test client is only a single thread,
    so I know the pool is not depleted, or anything like that. Something
    appears to be going haywire with the container.
    Does anybody have an idea what might be going on?
    Thanks.
    Greg

    Hi Greg,
    On a whim, I tried the same test with the thin driver, and the same
    delay occurred. This time, instead of a rollback being at the top ofthe
    thread dump stack trace, it was in some other Oracle call, with the
    top of the stack trace being a socketreader.are you using MTS? Is the db-server a SMP-box? Which exact patch level
    does your Oracle instance have? If yes, can you try to force a dedicated
    server connection and see if the problem disappears? I guess for an OCI
    connection you will have to edit tnsnames.ora, for a
    thin-driver-connection you would have to modify the connect string to
    something like this:
    jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOS
    T=<dnsname>)(PORT=1521)))(CONNECT_DATA=(SID=<your
    sid>)(SERVER=DEDICATED))))
    There is a bug in 8.1.6.0 which is supposed to be fixed in 8.1.6.3, but
    I can still reproduce it in 9i :-(. It makes the MTS-dispatcher hang for
    60 seconds if you have an SMP box with low load, so maybe this could be
    your problem.
    Daniel
    -----Original Message-----
    From: Greg Crider [mailto:[email protected]]
    Posted At: Wednesday, November 28, 2001 8:17 AM
    Posted To: ejb
    Conversation: 60 Second Delays in Client Getting Entity Bean (after
    finder method)
    Subject: Re: 60 Second Delays in Client Getting Entity Bean (after
    finder method)
    My client has been using OCI in production and development
    with JTS for
    over a year now without a problem. We went to OCI because
    there was some
    other problem with the thin driver. I'm not sure what the
    problem was,
    but Oracle acknowledged it, but said it wouldn't be corrected until
    Oracle 9i came out. We're still using 8.1.6, so from what I'm
    told, we
    don't use the thin driver.
    On a whim, I tried the same test with the thin driver, and the same
    delay occurred. This time, instead of a rollback being at the
    top of the
    thread dump stack trace, it was in some other Oracle call, with the
    top of the stack trace being a socketreader.
    Somebody else suggested that there may be a problem with
    transactions.
    Does this ring a bell? Again, I have a stateless session bean
    invoking a
    read-write entity bean, invoking a read-only entity bean. From
    everything I read, including weblogic docs, I should just rely on my
    deployment descriptor to control transactions and stay away from JTA.
    Hi Greg,
    I remeber long ago there were an issue with jts/oci driver combination
    when the connections were opened but never used...
    Buy the way, are there any specific reasons to use OCI instead of
    thin driver?
    "Greg Crider" <[email protected]> wrote in message
    news:[email protected]...
    I know. That's what I don't get. BTW Slava, I am using the
    latest OCI
    driver; thanks for the suggestion. I tried tweaking some of the Solaris
    kernel settings as relates to TCP, but that didn't clear up the problem
    either; however, it did change the frequency. Modifying the retransmit
    settings (very small values, sub 1.5 seconds) seemed to make it occur
    less frequently.
    It seems like its time for me to contact BEA Support and see what they
    can turn up. Thanks for the suggestions. If anybody else has an idea,
    let me know. I'm betting this is a simple, stupid config problem. I'll
    post back here when I find out what's up.
    But for some reason WebLogic code called the rollback:
    ... rollback
    at
    weblogic.jdbc.common.internal.ConnectionEnv.cleanup(Connection
    Env.java:499)
    at
    weblogic.jdbc.common.internal.ConnectionEnv.destroy(Connection
    Env.java:417)
    at
    weblogic.jdbc.common.internal.ConnectionEnv.destroy(Connection
    Env.java:393)
    at weblogic.jdbcbase.jts.Connection.close(Connection.java:274)
    at weblogic.jdbcbase.jts.Connection.commit(Connection.java:530)
    at
    weblogic.jdbcbase.jts.TxConnection.commitOnePhase(TxConnection
    .java:55)
    at
    weblogic.jts.internal.CoordinatorImpl.commitSecondPhase(Coordi
    natorImpl.java
    :484)
    at
    weblogic.jts.internal.CoordinatorImpl.commit(CoordinatorImpl.java:383)
    at weblogic.jts.internal.TxContext.commit(TxContext.java:255)
    Slava Imeshev <[email protected]> wrote:
    Hi Greg,
    Which version of OCI driver do you use? OCI driver proved to be
    not that stable as the thin driver. Could you try to download
    and to install the latest version of the OCI driver and
    let us know
    if it helps?
    Regards,
    Slava Imeshev
    [email protected]
    "Greg Crider" <[email protected]> wrote in message
    news:[email protected]...
    Yup, get fresh connection from the db connection pool,
    and close it
    >when
    I'm done. The logs don't indicate that I've ever exhausted the
    connection pool.
    It's interesting to note these problems are occurring on
    Solaris with
    Oracle OCI connections. Running the same code under Linux with thin
    driver connections works just fine.
    Weird. Do you obtain database connection from a
    datasource and close
    >it
    every time
    you use it?
    Greg Crider <[email protected]> wrote:
    Okay, this appears to be the offending thread. As it
    turns out, the
    >same
    behavior as first described in my initial post, is
    occurring this
    >time
    in the
    business method of the entity bean, as opposed to the
    finder. The
    getNextURL() is the business method in this case. I am using BMP, and
    the
    ejbLoad() and ejbStore() methods are not throwing any
    SQLExceptions.
    Also, I
    don't see anything in the error logs that indicate a
    EJB transaction
    failure.
    This being the case, why would an Oracle rollback be
    attempted? Am I
    misinterpretting this stack trace?
    "ExecuteThread-67" daemon prio=5 tid=0x14e300 nid=0x51 runnable
    [0xe7880000..0xe7881a30]
    at oracle.jdbc.oci8.OCIDBAccess.do_rollback(Native Method)
    at oracle.jdbc.oci8.OCIDBAccess.rollback(OCIDBAccess.java:417)
    at
    oracle.jdbc.driver.OracleConnection.rollback(OracleConnection.java:510)
    at
    weblogic.jdbc.common.internal.ConnectionEnv.cleanup(ConnectionEnv.java:4
    >99
    at
    weblogic.jdbc.common.internal.ConnectionEnv.destroy(Conne
    ctionEnv.java:4
    >17
    at
    weblogic.jdbc.common.internal.ConnectionEnv.destroy(Conne
    ctionEnv.java:3
    >93
    at weblogic.jdbcbase.jts.Connection.close(Connection.java:274)
    at weblogic.jdbcbase.jts.Connection.commit(Connection.java:530)
    at
    weblogic.jdbcbase.jts.TxConnection.commitOnePhase(TxConnec
    tion.java:55)
    at
    weblogic.jts.internal.CoordinatorImpl.commitSecondPhase(CoordinatorImpl.
    >ja
    va:484)
    at
    weblogic.jts.internal.CoordinatorImpl.commit(CoordinatorIm
    pl.java:383)
    at weblogic.jts.internal.TxContext.commit(TxContext.java:255)
    at
    weblogic.ejb.internal.StatefulEJBObject.postInvokeOurTx(StatefulEJBObjec
    >t.
    java:320)
    at
    weblogic.ejb.internal.BaseEJBObject.postInvoke(BaseEJBObje
    ct.java:845)
    at
    com.pi.speechport.ETO.LoadShare.ETOLoadShareEJBEOImpl.getNextURL(ETOLoad
    >Sh
    areEJBEOImpl.java:114)
    at
    com.pi.speechport.ETO.Transcription.ETOTranscriptionBusin
    ess.getVendorUR
    >L(
    ETOTranscriptionBusiness.java:146)
    at
    com.pi.speechport.ETO.Transcription.ETOTranscriptionBusin
    ess.transcribe(
    >ET
    OTranscriptionBusiness.java:193)
    at
    com.pi.speechport.ETO.Transcription.ETOTranscriptionEJBEO
    Impl.transcribe
    >(E
    TOTranscriptionEJBEOImpl.java:188)
    at
    com.pi.speechport.ETO.Transcription.ETOTranscriptionEJBEO
    Impl_WLSkel.inv
    >ok
    e(ETOTranscriptionEJBEOImpl_WLSkel.java:223)
    at
    weblogic.rmi.extensions.BasicServerObjectAdapter.invoke(B
    asicServerObjec
    >tA
    dapter.java:347)
    at
    weblogic.rmi.extensions.BasicRequestHandler.handleRequest
    (BasicRequestHa
    >nd
    ler.java:86)
    at
    weblogic.rmi.internal.BasicExecuteRequest.execute(BasicEx
    ecuteRequest.ja
    >va
    :15)
    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)
    Dimitri Rakitine wrote:
    Make a thread dump during these 60 seconds to see
    what server is
    >doing.
    Greg Crider <[email protected]> wrote:
    I am running WLS5.1 with SP10. I have a stateless
    EJB that gets a
    read-write BMP entity EJB. My test client that executes the
    stateless
    session bean periodically encounters long delays (60
    seconds or
    >more)
    when acquiring the entity bean using its finder
    method. Logging
    >shows
    the finder method is executing properly, and
    typically takes 180 ms
    >to
    locate the entity bean; however, from the stateless
    session beans
    side,
    it appears to take 60 seconds. The test client is
    only a single
    thread,
    so I know the pool is not depleted, or anything like that.
    Something
    appears to be going haywire with the container.
    Does anybody have an idea what might be going on?
    Thanks.
    Greg
    Dimitri
    Greg
    >__
    GREGORY K. CRIDER, Emerging Digital Concepts
    Systems Integration/Enterprise Solutions/Web &
    Telephony Integration
    (e-mail) [email protected]
    (web) http://www.EmergingDigital.com
    (voicemail) 866-474-4147
    (phone) 703-335-0974
    (cell) 703-851-5073
    (fax) 703-365-0223

  • I get a strange behavior of the tab bar and of the location bar in Firefox 29.0 for Mac.

    I have just installed Firefox 29.0 for Mac.
    I get a strange behavior of the tab bar and of the location bar with this new version.
    Instead of the location bar, I get two rows of symbols. And it's impossible to write anything in the location bar.
    (I'd like to add a screenshot, but I cannot find a way to do it.)

    Thank you for your tip.
    I found the culprit: it was an extension called RSS Icon 1.0.6.
    I removed it and now Firefox 29.0 is working perfectly.
    Now I'll have to find a replacement for that extension.
    Thank you once again. Your tip was essential.

  • Java.lang.IllegalStateException when trying to get a entity bean

    hi all,
    I wrote a simple container managed entity bean and deployed it. When i call the find all method of the entity bean following is the log trace of my exception
    com.sun.enterprise.resource.JdbcXAConnection$JdbcConnection@13974ba TX optimistic: false referenceCount =1 for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINER ( 1496): SQL statement<select t0."USER_ID", t0."LOGIN_NAME", t0."PASSWORD", t0."FIRST_NAME", t0."LAST_NAME", t0."EMAIL", t0."ADDRESS1", t0."ADDRESS2", t0."POSTALCODE", t0."CITY", t0."COUNTRY", t0."STATE", t0."ACCOUNT_STATUS", t0."CREATE_DATE", t0."MODIFY_DATE", t0."CREATED_BY", t0."MODIFIED_BY" from "EXPENSE_USER" t0> with no input values
    [22/Jul/2003:23:35:54] FINE ( 1496): <-> DBVendorType.getSpecialDBOperation():com.sun.jdo.spi.persistence.support.sqlstore.database.oracle.OracleSpecialDBOperation@1a92d3a.
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking key field iD as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): NullSemaphore.acquire() for PersistenceManagerImpl.cacheLock.
    [22/Jul/2003:23:35:54] FINER ( 1496): SQLStoreManager.getPersistenceConfig(), classType = com.expense.ejb.entity.container.UserBean1689033004_JDOState.
    [22/Jul/2003:23:35:54] FINEST ( 1496): NullSemaphore constructor() for SQLStateManager.
    [22/Jul/2003:23:35:54] FINE ( 1496): --> SqlStateManager.applyUpdates(), field = iD.
    [22/Jul/2003:23:35:54] FINEST ( 1496): iD = 1.
    [22/Jul/2003:23:35:54] FINEST ( 1496): NullSemaphore.release() for PersistenceManagerImpl.cacheLock.
    [22/Jul/2003:23:35:54] FINEST ( 1496): NullSemaphore.acquire() for SQLStateManager.
    [22/Jul/2003:23:35:54] FINEST ( 1496): loginName = root.
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field loginName as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): password = root.
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field password as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): firstName = super user.
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field firstName as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): lastName = null.
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field lastName as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): email = root@expen.
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field email as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): address1 = xxx .
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field address1 as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): address2 = xxx .
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field address2 as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): postalCode = 12345 .
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field postalCode as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): city = xxxx .
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field city as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): country = usa .
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field country as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): state = ca .
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field state as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): accountStatus = null.
    [22/Jul/2003:23:35:54] FINEST ( 1496): marking local field accountStatus as present.
    [22/Jul/2003:23:35:54] FINEST ( 1496): convertValue: 7/22/03 11:07 PM From: java.sql.Timestamp To: class java.lang.Long.
    [22/Jul/2003:23:35:54] FINEST ( 1496): createDate = 7/22/03 11:07 PM.
    [22/Jul/2003:23:35:54] FINEST ( 1496): NullSemaphore.release() for SQLStateManager.
    [22/Jul/2003:23:35:54] FINEST ( 1496): --- TransactionImpl.releaseConnection(): TX optimistic: false Inside Commit: false referenceCount: 0 for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINEST ( 1496): --- TransactionImpl.closeConnection() com.sun.enterprise.resource.JdbcXAConnection$JdbcConnection@13974ba for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINEST ( 1496): ---PersistenceManagerImpl.popCurrentWrapper() > current: com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerWrapper@2606b8 prev: null.
    [22/Jul/2003:23:35:54] FINE ( 1496): Exception in forceDestroyBean()
    java.lang.IllegalStateException: Primary key not available
         at com.sun.ejb.containers.EntityContextImpl.getPrimaryKey(EntityContextImpl.java:157)
         at com.sun.ejb.containers.EntityContainer.forceDestroyBean(EntityContainer.java:1252)
         at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:1792)
         at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:1608)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:529)
         at com.expense.ejb.entity.container.UserBean1689033004_ConcreteImpl_LocalHomeImpl.findAll(UserBean1689033004_ConcreteImpl_LocalHomeImpl.java:133)
         at jasper.usertest_jsp._jspService(_usertest_jsp.java:74)
         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
         at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
         at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
         at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
         at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
         at java.security.AccessController.doPrivileged(Native Method)
         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)
         at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
    [22/Jul/2003:23:35:54] FINEST ( 1496): Thread.currentThread()Tran[  Transaction:
    status = STATUS_ACTIVE
    Transaction Object = Transaction@17774593
    threads = 1
    ].afterCompletion: status = STATUS_ACTIVE, sync = null, STATUS_ROLLEDBACK for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINEST ( 1496): Thread[service-j2ee,5,main] Tran[   Transaction:
    status = STATUS_ACTIVE
    Transaction Object = Transaction@17774593
    threads = 1
    ].setStatus: STATUS_ACTIVE => STATUS_ROLLING_BACK for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINEST ( 1496): Thread[service-j2ee,5,main] Tran[   Transaction:
    status = STATUS_ROLLING_BACK
    Transaction Object = Transaction@17774593
    threads = 1
    ].internalRollback:status = STATUS_ROLLING_BACK ,txType: CMT for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINEST ( 1496): Thread[service-j2ee,5,main] Tran[   Transaction:
    status = STATUS_ROLLING_BACK
    Transaction Object = Transaction@17774593
    threads = 1
    ].setStatus: STATUS_ROLLING_BACK => STATUS_ROLLEDBACK for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINEST ( 1496): ---PersistenceManagerImpl.afterCompletion() process: true.
    [22/Jul/2003:23:35:54] FINEST ( 1496): Thread[service-j2ee,5,main] Tran[   Transaction:
    status = STATUS_ROLLEDBACK
    Transaction Object = Transaction@17774593
    threads = 1
    ].forget:status = STATUS_ROLLEDBACK ,txType: CMT for com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c.
    [22/Jul/2003:23:35:54] FINEST ( 1496): ---SQLPersistenceManagerFactory.releasePersistenceManager() PM:com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c for JTA Tx: com.sun.ejb.containers.PMTransactionImpl@2.
    [22/Jul/2003:23:35:54] FINEST ( 1496): ---SQLPersistenceManagerFactory.releasePersistenceManager() PM:com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl@12a585c for JTA Tx: null.
    [22/Jul/2003:23:35:54] FINEST ( 1496): <--SQLPersistenceManagerFactory.returnToPool().
    [22/Jul/2003:23:35:54] FINE ( 1496): EJB5018: Some unmapped exception occurred : [{0}]
    javax.ejb.EJBException: nested exception is: java.lang.ClassCastException
    java.lang.ClassCastException
         at com.expense.ejb.entity.container.UserBean1689033004_JDOState.jdoSetField(UserBean1689033004_JDOState.java:969)
         at com.sun.jdo.spi.persistence.support.sqlstore.model.FieldDesc.setValue(FieldDesc.java:337)
         at com.sun.jdo.spi.persistence.support.sqlstore.ResultDesc.setFields(ResultDesc.java:749)
         at com.sun.jdo.spi.persistence.support.sqlstore.ResultDesc.getResult(ResultDesc.java:635)
         at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:648)
         at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:500)
         at com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:989)
         at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:634)
         at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.execute(QueryImpl.java:455)
         at com.expense.ejb.entity.container.UserBean1689033004_ConcreteImpl.ejbFindAll(UserBean1689033004_ConcreteImpl.java:1249)
         at com.expense.ejb.entity.container.UserBean1689033004_ConcreteImpl_LocalHomeImpl.findAll(UserBean1689033004_ConcreteImpl_LocalHomeImpl.java:128)
         at jasper.usertest_jsp._jspService(_usertest_jsp.java:74)
         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
         at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
         at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
         at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
         at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
         at java.security.AccessController.doPrivileged(Native Method)
         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)
         at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
    javax.ejb.EJBException: nested exception is: java.lang.ClassCastException
         at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:1893)
         at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:1796)
         at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:1608)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:529)
         at com.expense.ejb.entity.container.UserBean1689033004_ConcreteImpl_LocalHomeImpl.findAll(UserBean1689033004_ConcreteImpl_LocalHomeImpl.java:133)
         at jasper.usertest_jsp._jspService(_usertest_jsp.java:74)
         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
         at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
         at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
         at org.apache.catalina.core.StandardWrapperValve.acces
    [22/Jul/2003:23:35:54] FINE ( 1496): EJB5019: Some application or system exception occurred : [UserBean]
    [22/Jul/2003:23:35:54] FINE ( 1496):
    [22/Jul/2003:23:35:55] SEVERE ( 1496): StandardWrapperValve[usertest]: Servlet.service() for servlet usertest threw exception
    javax.ejb.EJBException: nested exception is: java.lang.ClassCastException
    java.lang.ClassCastException
         at com.expense.ejb.entity.container.UserBean1689033004_JDOState.jdoSetField(UserBean1689033004_JDOState.java:969)
         at com.sun.jdo.spi.persistence.support.sqlstore.model.FieldDesc.setValue(FieldDesc.java:337)
         at com.sun.jdo.spi.persistence.support.sqlstore.ResultDesc.setFields(ResultDesc.java:749)
         at com.sun.jdo.spi.persistence.support.sqlstore.ResultDesc.getResult(ResultDesc.java:635)
         at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.executeQuery(SQLStoreManager.java:648)
         at com.sun.jdo.spi.persistence.support.sqlstore.SQLStoreManager.retrieve(SQLStoreManager.java:500)
         at com.sun.jdo.spi.persistence.support.sqlstore.impl.PersistenceManagerImpl.retrieve(PersistenceManagerImpl.java:989)
         at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.doExecute(QueryImpl.java:634)
         at com.sun.jdo.spi.persistence.support.sqlstore.query.QueryImpl.execute(QueryImpl.java:455)
         at com.expense.ejb.entity.container.UserBean1689033004_ConcreteImpl.ejbFindAll(UserBean1689033004_ConcreteImpl.java:1249)
         at com.expense.ejb.entity.container.UserBean1689033004_ConcreteImpl_LocalHomeImpl.findAll(UserBean1689033004_ConcreteImpl_LocalHomeImpl.java:128)
         at jasper.usertest_jsp._jspService(_usertest_jsp.java:74)
         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
         at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
         at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
         at org.apache.catalina.core.StandardWrapperValve.access$000(StandardWrapperValve.java:118)
         at org.apache.catalina.core.StandardWrapperValve$1.run(StandardWrapperValve.java:278)
         at java.security.AccessController.doPrivileged(Native Method)
         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:274)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:203)
         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:505)
         at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:157)
         at com.iplanet.ias.web.WebContainer.service(WebContainer.java:598)
    javax.ejb.EJBException: nested exception is: java.lang.ClassCastException
         at com.sun.ejb.containers.BaseContainer.processSystemException(BaseContainer.java:1893)
         at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:1796)
         at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:1608)
         at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:529)
         at com.expense.ejb.entity.container.UserBean1689033004_ConcreteImpl_LocalHomeImpl.findAll(UserBean1689033004_ConcreteImpl_LocalHomeImpl.java:133)
         at jasper.usertest_jsp._jspService(_usertest_jsp.java:74)
         at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.service(JspServlet.java:552)
         at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:368)
         at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:287)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
         at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:720)
         at org.apache.c
    [22/Jul/2003:23:36:15] FINE ( 1496): SingleSignOn[server1]: SSO expiration started. Current entries: 0
    [22/Jul/2003:23:36:15] FINE ( 1496): SingleSignOn[server1]: SSO cache will expire 0 entries.
    [22/Jul/2003:23:37:15] FINE ( 1496): SingleSignOn[server1]: SSO expiration started. Current entries: 0
    [22/Jul/2003:23:37:15] FINE ( 1496): SingleSignOn[server1]: SSO cache will expire 0 entries.
    following is the ejb-jar.xml part of this entity bean
    <entity>
    <ejb-name>UserBean</ejb-name>
    <local-home>com.expense.ejb.entity.container.LocalUserHome</local-home>
    <local>com.expense.ejb.entity.container.LocalUser</local>
    <ejb-class>com.expense.ejb.entity.container.UserBean</ejb-class>
    <persistence-type>Container</persistence-type>
    <prim-key-class>java.lang.Integer</prim-key-class>
    <reentrant>False</reentrant>
    <cmp-version>2.x</cmp-version>
    <abstract-schema-name>userSchema</abstract-schema-name>
    <cmp-field>
    <field-name>loginName</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>password</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>iD</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>firstName</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>email</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>lastName</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>address1</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>address2</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>postalCode</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>city</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>state</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>country</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>accountStatus</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>createdBy</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>modifiedBy</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>modifyDate</field-name>
    </cmp-field>
    <cmp-field>
    <field-name>createDate</field-name>
    </cmp-field>
    <primkey-field>iD</primkey-field>
    <query>
    <query-method>
    <method-name>findByLoginName</method-name>
    <method-params>
    <method-param>java.lang.String</method-param>
    </method-params>
    </query-method>
    <ejb-ql> select object(l) from userSchema l WHERE l.loginName = ?1</ejb-ql>
    </query>
    <query>
    <query-method>
    <method-name>findByCreateDate</method-name>
    <method-params>
    <method-param>java.lang.Long</method-param>
    </method-params>
    </query-method>
    <ejb-ql>select object(l) from userSchema l where l.createDate = ?1 </ejb-ql>
    </query>
    <query>
    <query-method>
    <method-name>findByModifyDate</method-name>
    <method-params>
    <method-param>java.lang.Long</method-param>
    <method-param>java.lang.Long</method-param>
    </method-params>
    </query-method>
    <ejb-ql>select object(l) from userSchema as l where l.modifyDate between ?1 and ?2</ejb-ql>
    </query>
    <query>
    <query-method>
    <method-name>findAll</method-name>
    <method-params>
    </method-params>
    </query-method>
    <ejb-ql>SELECT OBJECT(L) FROM userSchema L </ejb-ql>
    </query>
    </entity>
    </enterprise-beans>
    <assembly-descriptor>
    <container-transaction>
    <method>
    <ejb-name>UserBean</ejb-name>
    <method-name>*</method-name>
    </method>
    <trans-attribute>Required</trans-attribute>
    </container-transaction>
    </assembly-descriptor>
    can anyone suggest me on howto solve this problem

    I suspect that there is a type mismatch somewhere in the CMP fields (there is a ClassCastException in the trace).
    Please check the generated code (UserBean1689033004_JDOState.java line 969) that can be found under
    <appserver-install>/domains/domain1/server1/generated/ejb/j2ee-apps/<app-name>/<packages...>/
    Thank you,
    -marina

  • Strange Behavior of GET PERNR

    Hi All,
    I am facing a strange behavior with GET Event for PNP LDB.
    In my selection-screen, i have fields like Payroll Area, Current Period, Other Period, personnel number.
    Usually, i populate Payroll area, other period(say 06-2007) and input some personnel number.
    When i tried to debug for one personnel, its not at all going into GET PERNR event...it directly goes to END-OF-SELECTION event.
    Please help on this.
    Regards,
    Kiran Chennapai

    Hi Manoj,
    The below is some part for my coding:
    START-OF-SELECTION.
      IF pnptimr9 = 'X'.
        PERFORM f_get_next_period.    "Take next period when the selection
        " is current period
      ENDIF.
    Get deatils of actions and pay-scales
      PERFORM f_get_data.
      CLEAR: g_num_processed, g_num_skipped, g_num_success, g_num_error.
    GET pernr.
      rp_provide_from_last p0001 space pn-begda pn-endda.
      IF pnp-sw-found = 1.
    Verify whether the personnel is under the given Payroll area or not
        CHECK p0001-abkrs = pnpxabkr.
        IF p_eegrp IS NOT INITIAL.
    Verify personnel's employee group is under the given EEgroup
          CHECK p_eegrp = p0001-persg.
        ENDIF.
    start processing for the selected personnel
        PERFORM f_process_data.
      ENDIF.
    END-OF-SELECTION.
    Do increment process for all the selected personnel
      IF NOT git_process[] IS INITIAL.
        PERFORM f_increment_process.
      ENDIF.
    When i tried to put a break-point at the first statement in the GET event and executed, its not going into GET event at all.(personnel number is existing in the system)
    Regards,
    Kiran Chennapai

  • Strange Session/Entity Bean Cross-Instance Calls in Cluster

    In one of our enviroments, we are seeing session entity bean cross-instance
              calls that are hard to explain. The following is our configuration:
              The cluster contains 4 instances on 2 machines (2 on each machine). The same
              beans are deployed to each instance. "jndi.properties" is on the classpath
              for the each instance with jndi provider url = mach1inst1-ip, mach1inst2-ip,
              mach2inst1-ip, mach2inst2-ip:70001. Same servlets are also deployed to each
              instances.
              Requests from the web are load balanced through weblogic's proxy plugin for
              IPlanet and are forwarded to the 4 weblogic cluster instances. The servlet
              processing the requests calls a stateless session bean which uses an entity
              bean. The entity bean is configured with "home-is-clusterable" set to
              "false".
              What we have observed is that when all 4 instances are up, sometimes (even
              when the load is not high) the session bean is accessing entity bean from an
              instance on one machine to an instnace on another machine, while if only one
              machine (with 2 instances) is up, we don't see such calls.
              My theory is that because the jndi provider url is the same for all
              instances, the jndi lookup from each instance goes to the instance bound to
              the first IP specified in the provider url: machine 1 istance 1. If the
              request is from machine 2, because of co-location optimization, even though
              the home stub is from machine 1 instance 1, the session bean returned from
              the home stub actually is from machine 2. However, when the session bean
              does jndi lookup to get an entity bean home, the home stub is from machine 1
              and instance 1. And unfortunately, because the entity bean home is not
              clusterable, the stub can only point back to machine 1, co-location can not
              work. Thus entity bean from machine 1 is referenced by the session bean
              located on machine 2. I do not have a chance to verify this. But it seems to
              make sense to me.
              Unfortunately, I don't feel that I have a theory to explain why we don't see
              cross instance session entity bean calls when only 1 machine is up (with 2
              instances).
              Any ideas or hints would be greatly appreciated.
              Thanks,
              David Chen
              

    rs = stmt.executeQuery() , insert statement is not a query. So use executeUpdate.

  • Can't get BMP Entity Bean Instance!!

    Hello
    I have created a BMP Entity bean, and put on the findPrimaryKey method this code:
    try {
    context = new InitialContext();
    DataSource ds = (DataSource) context.lookup(nombreConexion);
    conn = ds.getConnection();
    stmt = conn.createStatement();
    rs = stmt.executeQuery("select count(upc) from musiccdejb where upc='"+ primaryKey +"'");
    if (rs!=null && rs.next()) {    
    countNumber = rs.getInt(1);
    if (countNumber!=1) {
    throw new Exception();
    catch (SQLException e) {
    System.out.println("Error ejbFindPrimaryKey"+e);
    catch (Exception e1) {
    System.out.println("Otro error ejbFindPrimaryKey"+e1);
    Everything there seem to be ok, because the select return 1, so the primary key exist, but after that the container doesn't get the information for this entity bean, everything is null when I tried to acces the information.
    Context ctx = new InitialContext();
    MusicCDBMPHome musicCDHome = (MusicCDBMPHome)ctx.lookup("java:comp/env/ejb/MusicCDBMP");
    boolean found = false;
    try {
    musicCDObj = musicCDHome.findByPrimaryKey("1");
    found = true;
    } catch (Exception e) {
    found = false;
    if (found) {
    out.println(musicCDObj.getUpc());
    out.println(musicCDObj.getTitle());
    Please help me, I am working with JDeveloper 9i Release 2 and OC4J Standalone version 9.0.2.
    Ana Maria

    Yes, I alredy did that, and this is te content of my ejbLoad:
    String upc = (String)entityContext.getPrimaryKey();
    ResultSet rs = null;
    try {
    context = new InitialContext();
    DataSource ds = (DataSource) context.lookup(nombreConexion);
    conn = ds.getConnection();
    stmt = conn.createStatement();
    rs = stmt.executeQuery("select count(upc) from musiccdejb where upc='"+ upc +"'");
    if (rs!=null && rs.next()) {
    if (rs.getInt(1)!=1) {
    throw new Exception();
    catch (SQLException e) {
    System.out.println("Error ejbLoad"+e);
    catch (Exception e1) {
    System.out.println("Otro error ejbLoad"+e1);
    Another suggestion??
    Thanks
    Ana Maria

  • My ipad2 is getting lazy with the wifi. On any router it doesn't get the signal by itself, unless I'm so close that the pad and the antenna are touching. Other solution, to turn off and on again the wifi button on the iPad. This strange behavior is new...

    My ipad2 is getting lazy with the wifi. On any router it doesn't get the signal by itself, unless I'm so close that the pad and the antenna are touching. Other solution, to turn off and on again the wifi button on the iPad. This strange behavior is new, before my iPad was blazing fast at getting any known wifi connection. Sme help please ??

    it sure sounds like the battery is defect

  • Problem with getting Entity Beans refreshed within Session bean methods

    I hav following code in session and entity beans:
    Session bean pseudo code: (PrimaryKey is primary key class for the entity
    bean referred here, and MySessionHome is the home interfac class for this
    session bean).
    public class MySession implements SessionBean {
    // This method is present in remote interface class as well.
    public void methodA(PrimaryKey pk) {
    // code to find entity bean by primary key specified.
    update the entity bean, and mark it as isModified.
    public void methodB(PrimaryKey pk) {
    // code to find entity bean by primary key specified.
    do something.
    public void methodC() {
    MySessionHome sessHome = code to lookup sessionhome from JNDI.
    MySessionRI sess = sessHome.create(); // MySessionRI is the remote
    interface class for MySession
    PrimaryKey pk = new PrimaryKey(params);
    sess.methodA(); // LINE ABC1
    sess.methodB(); // LINE ABC2
    all the entity and session bean methods have required as the TX attribute.
    In methodB() on LINE ABC2, the entity bean obtained by findByPrimaryKey does
    not reflect the changes made in call to methodA() on LINE ABC1.
    Now if I change the LINE ABC1 and LINE ABC2 to
    methodA(); // LINE ABC1
    methodB(); // LINE ABC2
    in this case the entity bean obtained in methodB() has the changes made in
    methodA().
    Any idea why this is happening?

    Hi ad13217 and thanks for reply.
    I'm sorry but my code is like this:
    javax.naming.Context ctx=new javax.naming.InitialContext();
    arguments was an error on copy, but it doesn't work.
    Thanks
    Fil

  • MDB gets cannot find recently created Entity Bean

    I have a session bean that creates several entities beans, and puts a message onto
    JMS queue. A MDB is configured to read the queue, and in onMessage(), it calls
    findByPrimaryKey() for one of the newly created EntityBeans. However, the entity
    bean cannot be found.
    All of the beans in question are using container managed transactions, and all
    have transaction required. The entity bean that I'm looking for is using optimistic
    concurrency. I cannot change it to exclusive without redesigning a major part
    of the system, which have solved a similar problem that I encounted earlier that
    did not involve any message driven beans.
    The only way that I got it to work is put in Thread.sleep(5000) right before calling
    the finder. Does anyone know of any alternatives besides having the MDB sleep?

    No, this will work fine with the existing server. If the publish is
    part of the JTA transaction, then no one can consume the message until
    the original JTA transaction has committed.
    -- Rob
    Rajesh Mirchandani wrote:
    XA defines that a transaction's individual operations will either fail or
    succeed atomically. XA can not, and does not define that a transaction's
    individual operations occur exactly simultaneously.
    The WL transaction monitor does not currently provide a way to serialize a
    transactions commit operations on its component resource managers.
    There is an enhancement filed for this, I guess. Follow up with BEA support.
    Rob Woollen wrote:
    Vina Wang wrote:
    The JMS send is part of the transaction, sort of. The call is within
    the session
    bean transaction, but I'm not using transacted session for
    JMSPulisher. Would
    that fix the problem?Sadly this is a confusing aspect of JMS. You want a non-transacted
    session because you want it to participate in the global transaction
    that the EJB started. Also, make sure that you've enabled user
    transactions on your connection factory.
    There's more info here:
    http://edocs.bea.com/wls/docs70/faq/jms.html#252635
    Let us know if you're still having problems.
    -- Rob
    I know that the transaction hasn't been commited, but I was monitoring
    database
    via SQL call when I tried this. There was about 2 second delay on my
    development
    machine.
    Rob Woollen wrote:
    My guess is the MDB is receiving the message before your "create entity
    bean" transaction has committed. Is the JMS send part of the "create
    entity bean" transaction? It probably should be.
    You can easily prove this by writing a few lines of JDBC to hit the
    database and check for your primary key.
    I would not recommend changing to exclusive or using the Thread.sleep.
    -- Rob
    Vina Wang wrote:
    I have a session bean that creates several entities beans, and putsa
    message onto
    JMS queue. A MDB is configured to read the queue, and in onMessage(),
    it calls
    findByPrimaryKey() for one of the newly created EntityBeans. However,
    the entity
    bean cannot be found.
    All of the beans in question are using container managed transactions,
    and all
    have transaction required. The entity bean that I'm looking for is
    using optimistic
    concurrency. I cannot change it to exclusive without redesigning a
    major part
    of the system, which have solved a similar problem that I encounted
    earlier that
    did not involve any message driven beans.
    The only way that I got it to work is put in Thread.sleep(5000) right
    before calling
    the finder. Does anyone know of any alternatives besides having the
    MDB sleep?
    Rajesh Mirchandani
    Developer Relations Engineer
    BEA Support

  • Entity bean doesn't return hours/min/sec from a Date database field

    Hello:
    I'mm working with Sun One 7 Appserv and Oracle 9i
    I'm having a strange behaviour with getter methods in entity beans when the return value is a Timestamp
    In database, the field's type is Date, but the return value's type is Timestamp
    In this case, the hours/min/sec values return into Timestamp value are always 00:00:00
    For example: in database , F field is a Date and has got the value "12/12/2006 12:30:00"
    After Timestamp t = entityRef.getF() call , t has got the "12/12/2006 00:00:00" value
    The strange case is that in anothers AS ( like JBoss ) , the same code returns right
    Any problem with Oracle 9i in SunOne 7 ? Any problem with JDBC driver ?
    Thanks !
    Best regards

    Well, I found the solution.
    The problem was the ojdbc14.jar driver, which made wrong schema files.
    Exactly, with the bad ojdbc14.jar, generated this entry
    <_type>91</_type>
    when the right for time types is
    <_type>91</_type>
    I dont know beause the new ojdbc14.jar works fine, but I paste its size
    ojdbc14.jar good : 1181679 bytes

  • NON-transactional session bean access entity bean

    We are currently profiling our product using Borland OptmizeIt tool, and we
    found some interesting issues. Due to our design, we have many session beans which
    are non transactional, and these session beans will access entity beans to do
    the reading operations, such as getWeight, getRate, since it's read only, there
    is no need to do transaction commit stuff which really takes time, this could
    be seen through the profile. I know weblogic support readonly entity bean, but
    it seems that it only has benefit on ejbLoad call, my test program shows that
    weblogic still creates local transaction even I specified it as transaction not
    supported, and Transaction.commit() will always be called in postInvoke(), from
    the profile, we got that for a single method call, such as getRate(), 80% time
    spent on postInvoke(), any suggestion on this? BTW, most of our entity beans are
    using Exclusive lock, that's the reason that we use non-transactional session
    bean to avoid dead lock problem.
    Thanks

    Slava,
    Thanks for the link, actually I read it before, and following is what I extracted
    it from the doc:
    <weblogic-doc>
    Do not set db-is-shared to "false" if you set the entity bean's concurrency
    strategy to the "Database" option. If you do, WebLogic Server will ignore the
    db-is-shared setting.
    </weblogic-doc>
    Thanks
    "Slava Imeshev" <[email protected]> wrote:
    Hi Jinsong,
    You may want to read this to get more detailed explanation
    on db-is-shared (cache-between-transactions for 7.0):
    http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1127563
    Let me know if you have any questions.
    Regards,
    Slava Imeshev
    "Jinsong HU" <[email protected]> wrote in message
    news:[email protected]...
    Thanks.
    But it's still not clear to me in db-is-shared setting, if I specifiedentity
    lock as database lock, I assumed db-is-shared is useless, because foreach
    new
    transaction, entity bean will reload data anyway. Correct me if I amwrong.
    Jinsong
    "Slava Imeshev" <[email protected]> wrote:
    Jinsong,
    See my answers inline.
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    Hi Slava,
    Thanks for your reply, actually, I agree with you, we need to
    review
    our db
    schema and seperate business logic to avoid db lock. I can not say,guys,
    we need
    to change this and that, since it's a big application and developedsince
    EJB1.0
    spec, I think they are afraid to do such a big change.Total rewrite is the worst thing that can happen to an app. The
    better aproach would be identifying the most critical piece and
    make a surgery on it.
    Following are questions in my mind:
    (1) I think there should be many companies using weblogic serverto
    develop
    large enterprise applications, I am just wondering what's the maintransaction/lock
    mechanism that is used? Transional session / database lock,
    db-is-shared
    entity
    I can't say for the whole community, as for my experience the standard
    usage patthern is session fasades calling Entity EJBs while having
    Required TX attribute plus plain transacted JDBC calls for bulk
    reads or inserts.
    is the dominant one? It seems that if you speficy database lock,
    the
    db-is-shared
    should be true, right?Basically it's not true. One will need db-is-shared only if thereare
    changes
    to the database done from outside of the app server.
    (2) For RO bean, if I specify read-idle-timeout to 0, it shouldonly
    load
    once at the first use time, right?I assume read-timeout-seconds was meant. That's right, but if
    an application constantly reads new RO data, RO beans will be
    constantly dropped from cache and new ones will be loaded.
    You may want to looks at server console to see if there's a lot
    of passivation for RO beans.
    (3) For clustering part, have anyone use it in real enterpriseapplication?
    My concern, since database lock is the only way to choose, how aboutthe
    affect
    of ejbLoad to performance, since most transactions are short live,if high
    volume
    transactions are in processing, I am just scared to death about
    the
    ejbLoad overhead.
    ejbLoad is a part of bean's lifecycle, how would you be scared ofit?
    If ejbLoads take too much time, it could be a good idea to profile
    used SQLs. Right index optimization can make huge difference.
    Also you may want cosider using CMP beans to let weblogic
    take care about load optimization.
    (4) If using Optimization lock, all the ejbStore need to do
    version
    check
    or timestamp check, right? How about this overhead?As for optimistic concurrency, it performs quite well as you can
    use lighter isolation levels.
    HTH,
    Slava Imeshev
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    We are using Exclusive Lock for entity bean, because of we do
    not
    want
    to
    load
    data in each new transaction. If we use Database lock, that means
    we
    dedicate
    data access calls to database, if database deadlock happens,
    it's
    hard
    to
    detect,
    while using Exclusive lock, we could detect this dead lock in
    container
    level.
    The problem is, using Exclusive concurrency mode you serialize
    access to data represented by the bean. This aproach has negative
    effect on ablity of application to process concurrent requests.As
    a
    result the app may have performance problems under load.
    Actually, at the beginnning, we did use database lock and usingtransactional
    The fact that you had database deadlocking issues tells that
    application logic / database schema may need some review.
    Normally to avoid deadlocking it's good to group database
    operations mixing in updattes and inserts into one place so
    that db locking sequence is not spreaded in time. Moving to
    forced serialized data access just hides design/implementation
    problems.
    session bean, but the database dead lock and frequent ejbLoad
    really
    kill
    us,
    so we decided to move to use Exclusive lock and to avoid dead
    lock,
    we
    change
    some session bean to non-transactional.Making session beans non-transactions makes container
    creating short-living transactions for each call to entity bean
    methods. It's a costly process and it puts additional load to
    both container and database.
    We could use ReadOnly lock for some entity beans, but since weblogicserver will
    always create local transaction for entity bean, and we found
    transaction
    commit
    is expensive, I am arguing why do we need create container leveltransaction for
    read only bean.First, read-only beans still need to load data. Also, you may seeRO
    beans
    contanly loading data if db-is-shared set to true. Other reason
    can
    be
    that
    RO semantics is not applicable the data presented by RO bean (forinstance,
    you have a reporting engine that constantly produces "RO" data,
    while
    application-consumer of that data retrieves only new data and neverasks
    for "old" data). RO beans are good when there is a relatively stable
    data
    accessed repeatedly for read only access.
    You may want to tell us more about your app, we may be of help.
    Regards,
    Slava Imeshev
    I will post the performance data, let's see how costful
    transaction.commit
    is.
    "Cameron Purdy" <[email protected]> wrote:
    We are currently profiling our product using Borland
    OptmizeIt
    tool,
    and we
    found some interesting issues. Due to our design, we have
    many
    session
    beans which
    are non transactional, and these session beans will access
    entity
    beans
    to
    do
    the reading operations, such as getWeight, getRate, since
    it's
    read
    only,
    there
    is no need to do transaction commit stuff which really takes
    time,
    this
    could
    be seen through the profile. I know weblogic support readonly
    entity
    bean,
    but
    it seems that it only has benefit on ejbLoad call, my test
    program
    shows
    that
    weblogic still creates local transaction even I specified
    it
    as
    transaction not
    supported, and Transaction.commit() will always be called
    in
    postInvoke(),
    from
    the profile, we got that for a single method call, such as
    getRate(),
    80%
    time
    spent on postInvoke(), any suggestion on this? BTW, most of
    our
    entity
    beans are
    using Exclusive lock, that's the reason that we use
    non-transactional
    session
    bean to avoid dead lock problem.I am worried that you have made some decisions based on an improper
    understand of what WebLogic is doing.
    First, you say "non transactional", but from your description
    you
    should
    have those marked as tx REQUIRED to avoid multiple transactions
    (since
    non-transactional just means that the database operation becomesits
    own
    little transaction).
    Second, you say you are using exclusive lock, which you shouldonly
    use
    if
    you are absolutely sure that you need it, (and note that it
    does
    not
    work in
    a cluster).
    Peace,
    Cameron Purdy
    Tangosol, Inc.
    http://www.tangosol.com/coherence.jsp
    Tangosol Coherence: Clustered Replicated Cache for Weblogic
    "Jinsong Hu" <[email protected]> wrote in message
    news:[email protected]...
    >

Maybe you are looking for