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 PMHi,
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.
GregHi 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 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 problemI 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 -
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 ChennapaiHi 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 MariaYes, 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, 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 regardsWell, 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.
ThanksSlava,
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
-
Photos converted to pdf files by Adobe 9.0??
I am a rookie user. I recently downloaded Adobe 9.0 per a prompt on my PC. I went in today to look at some photos that I have had on this PC for about a year - save in standard 'folder-file-jpeg' format. Somehow, and I did not do this since I would n
-
I have created a handbook/booklet with the Beginners Guide, in a much more readable format instead of messy paragraphs and links when it is printed out normally. I will be selling them in my shop, Software Care (see my sig) for £1.99 + P&P. See http:
-
Hi!! I am researching Resource Bundles and how they work and have a question. Do you have to use Locales to determine which bundle to use? You see I am developing a product that will only be used in the US but will be used by several different compan
-
Error installing business content update rules
Hi, I'm trying to install the below updates rules from the business content 0PLANT$T 0PLANT_TEXT 53AFFWD74OI3CT3RDE3RI9THU 0PLANT 0PLANT_ATTR 5UZVD7UWYN4T81H24YBKGH6KY I get the error IC=0PLANT$T IS=0PLANT_TEXT syntax error: rows 0 Long
-
Please help me!--rendering makes the images or video blurry (very pixelated) deteriorates the image Adobe Premier Elements 13 need help! .jpg and mpeg images, but I have never "rendered" before since I got APE 13 about 6 weeks ago. I am desperat