WebLogic 12.1.3 Cluster EJB Timer with filesystem

I'm running a WebLogic 12.1.3 Cluster and need to create clustered EJB 3.x Timers.
Can I use a filesytem as a persistent cluster store instead of a DB? The application itself doesn't need a DB so it would be overkill for us to deploy RAC just to get clustered EJB Timers.

Yes: As long as there is one server in the cluster still running, the timers will still function, the application may run slower though. When all servers in the cluster stop, the timers will stop running. When at least one of the servers in the cluster restarts again, the timers will start running.
Check: JEE blog: How to use EJB 3 timer in a weblogic 10 cluster environment

Similar Messages

Memory leak in a client using EJBs deployed in a Bea Weblogic 10.0.0 cluste

Hi all,
We are having a memory leak in a client using stateless EJBs deployed in cluster. The client is a Tomcat 6.0.18 with java 6 but it is reproduced using Tomcat 5 with java 5. The client is calling a Weblogic Server 10.0 making
calls to an EJB deployed in cluster that has two instances installed in two different machines.
The client works fine if we shutdown one of the server instances and so when the client is using only one instance.
Resuming the environment:
Client Side:
1 HP-Itanium machine with HP-UX.
1 Tomcat 6 with java 6 (reproduced with java 5)
Bea Weblogic client (wlclient.jar) for Weblogic 10.0.0
Server Side:
2 HP-Itanium machines with HP-UX
Bea Weblogic Server 10.0.0 installed in both machines
An unique domain
Two Bea instances (one per machines) associated to a Bea Cluster
EJBs deployed in both instances
We have monitored the memory consumed in Tomcat and we have noticed that the VM memory PS OLD GEN grows up permanently when we make tests having the two server side Bea Instances up. We have extended
the memory VM parameters in Tomcat client till 1G and it's only a way to delay the end: the free memory is empty, the GC is not able to free no more byte and the CPU is 100% consumed by the GC work. At the end Tomcat Client
doesn't accept more http petitions and must be restarted.
Besides, we have studied the VM memory in Tomcat using jmap and importing it using Eclipse Memory Analyzer. We have seen some strange memory blocks of several Mbytes that are always growing up and that are stored
under data structures in the package com.sun.corba:
com.sun.corba.se.impl.legacy.connection.SocketFactoryConnectionImpl (4.5Mb)
|
-> com.sun.corba.se.impl.transport.CorbaResponseWaitingRoomImpl
|
-> java.util.Hashtable
|
-> java.util.Hashtable$Entry
|
-> java.util.Hashtable$Entry
-> java.util.Hashtable$Entry
-> java.util.Hashtable$Entry
Has anybody any idea about this problem?
Thanks in advance.

Hi all,
We are having a memory leak in a client using stateless EJBs deployed in cluster. The client is a Tomcat 6.0.18 with java 6 but it is reproduced using Tomcat 5 with java 5. The client is calling a Weblogic Server 10.0 making
calls to an EJB deployed in cluster that has two instances installed in two different machines.
The client works fine if we shutdown one of the server instances and so when the client is using only one instance.
Resuming the environment:
Client Side:
1 HP-Itanium machine with HP-UX.
1 Tomcat 6 with java 6 (reproduced with java 5)
Bea Weblogic client (wlclient.jar) for Weblogic 10.0.0
Server Side:
2 HP-Itanium machines with HP-UX
Bea Weblogic Server 10.0.0 installed in both machines
An unique domain
Two Bea instances (one per machines) associated to a Bea Cluster
EJBs deployed in both instances
We have monitored the memory consumed in Tomcat and we have noticed that the VM memory PS OLD GEN grows up permanently when we make tests having the two server side Bea Instances up. We have extended
the memory VM parameters in Tomcat client till 1G and it's only a way to delay the end: the free memory is empty, the GC is not able to free no more byte and the CPU is 100% consumed by the GC work. At the end Tomcat Client
doesn't accept more http petitions and must be restarted.
Besides, we have studied the VM memory in Tomcat using jmap and importing it using Eclipse Memory Analyzer. We have seen some strange memory blocks of several Mbytes that are always growing up and that are stored
under data structures in the package com.sun.corba:
com.sun.corba.se.impl.legacy.connection.SocketFactoryConnectionImpl (4.5Mb)
|
-> com.sun.corba.se.impl.transport.CorbaResponseWaitingRoomImpl
|
-> java.util.Hashtable
|
-> java.util.Hashtable$Entry
|
-> java.util.Hashtable$Entry
-> java.util.Hashtable$Entry
-> java.util.Hashtable$Entry
Has anybody any idea about this problem?
Thanks in advance.

"Singleton" EJB Timer in GlassFish 2.1 cluster?

Hi,
suppose on a GlassFish 2.1 cluster (two instances on one machine) you deploy an ejb app which contains an ejb timer. The ejb timer executes every 60 seconds.
Following questions come to my mind:
1. After deployment do you have (the same) ejb timer on each instance (both using the same connection pool) ?
2. If so, how it is guaranteed that every 60 seconds only one timer is executed?
3. Is it possible to have a "singleton" timer for all instances in a cluster?
Thx for your help.

EJB 3.0 only supports programmatic timer creation. The app can contain an enterprise bean component that supports timer callbacks (a "timed object" in spec parlance) , but the actual timers can only be created by calling TimerService.createTimer(). Given that :
1. There is no automatic timer creation as a result of deployment. Some developers approximate automatic timer creation
by calling a stateless session bean method from a web application initialization callback, but from the ejb container's perspective
that's just a normal run-time timer creation. In all cases you'll have as many timers as the number of times TimerService.createTimer() was called.
2. In a cluster, for each unique timer, each timer timeout callback will happen in only one server instance in the cluster. We do that
by using the underlying timer database and an ownership semantic that assigns each timer to a particular server instance. During
failover, ownership of timers owned by the failed server instance is reassigned to a healthy server instance. Note that this only applies
to timeout callbacks. All timers created by a bean are always visible to any instances of that bean in any server instance in the cluster.
In other words, getTimers() always returns the total number of timers associated with the bean component, even if the callbacks
happen in a different server instance in the cluster.
3. Each call to TimerService.createTimer() is unique across the cluster. However, the burden of ensuring that createTimer() is only
called once is on the application. EJB 3.1 will address this problem by adding "automatic timers". These are timers that are
specified via metadata (annotation or ejb-jar.xml) and are created automatically as a result of deployment.

Weblogic 7 SP2 - problem in ejb-jar.xml

Hi,
I have a problem when trying to move from Weblogic 7 to 7 SP2. In some of our
ejb-jar.xml descriptors we have something like the following:
<!ENTITY ENTITY_PROP SYSTEM "Config/entity_config.txt">
then used this later on in the descriptor:
<env-entry-value>&ENTITY_PROP;</env-entry-value>
In all previous versions this would work fine with the Config directory sat in
the domain directory but when we are trying to move to SP2 the ejb's are failing
at deployment time with errors like:
weblogic.xml.process.XMLParsingException: File "zip://C/bea/user_projects/mydomain/myserver/.wlnotdelete/ScanServer/MkpCodeServerEJB.jar!/META-INF/Config/entity_config.txt"
not found. - with nested exception:
[org.xml.sax.SAXParseException: File "zip://C/bea/user_projects/mydomain/myserver/.wlnotdelete/ScanServer/MkpCodeServerEJB.jar!/META-INF/Config/entity_config.txt"
not found.].....
What has changed? What can I do to solve the problem?
thank you,
Ian

Hi,
Please ignore the previous post. it is a bug in 10.3. Please contact the support and get the patch. The bug no is 8180493. thanks.
-Albert
Edited by: zhao.yong on 2009-6-22 下午11:17

Stateless Bean - scope of instance variable in EJB Timer call back function

Hi,
I would like to know on the scope of an instance variable of a Stateless Bean object,
when used in a EJB Timer call back.Let me explain this in more detail below.
I have a requirement to use a EJB Timer.
For this, I have created a stateless object since Timer creation needs to be done
from a stateless bean. I have a member variable "count" of the stateless bean class.
In the timer call back(ejbTimeout), I am able to use this count variable during
each time of the call back, and the value of this variable is also updated properly.
I have a few queries with respect to the above behaviour:
1) Does stateless bean object not get destroyed once the Timer is created from the Bean?
2) If the Bean object is not destroyed, then when does the bean object get destroyed?
3) If both (1) and (2) are not true, then can anyone explain on how the above behaviour is possible?
Thanks in advance,
Ulrich

Hi Ulrich,
The ejb timer is associated with the stateless session bean component, not with a particular bean instance. There is no formal relationship between the bean instance that called createTimer() and the bean instance on which the timer callback happens. If they're the same in your test run that's just a coincidence and not something your application should be depending on.
In the stateless session bean model, the container can create and destroy stateless session bean instances at any time. The container is free to pick any stateless session bean instance to service any client invocation or timer callback. If you need to pass context into a timer callback, one way to do it is via the timer "info" object. However, the info object is immutable so it wouldn't be a good match for a counter. You could of course always just use a database for any necessary coordinated state.
--ken

Running the same code multiple times with different paramters automatically

Hi guys,
I want to run the same code multiple times with different paramters automatically. Actually, I am doing some sample scans which takes around 2 hours n then I have to be there to change the paramters and run it again. Mostly I do use folowing paramters only
X_Intial, X_Final, X-StepSize
Y_Intial, Y_Final, Y-StepSize
Thanks,
Dushyant

All you have to di is put all of the parameters for each run into a cluster array. Surround your main program with a for loop and wire the cluster array through the for loop. A for loop will autoindex an input array so inside the for loop you just have to unbundle the cluster to get the parameters for each run.
Message Edited by Dennis Knutson on 07-13-2006 07:50 AM
Attachments:
Cluster Array.JPG ‏9 KB

EJB Websphere with Universal Test Client

Hi,
I developed an ejb application using WSAD. I developed a universal test client in WSAD. The business logic method which i have written is argumented. When i am testing ejb applicatin with Universal test client, i should see text box to enter value for that arguments. But i am not getting that provision.
The method definition is like this:
private long [] employeeIDs = { 10010, 10023, 10045, 10051, 10061 };
private String [] employees = {"Frank", "Sam", "Maddy", "Jack", "Lorette" };
public String getEmployeeName( long employeeID )
throws javax.ejb.CreateException, java.rmi.RemoteException
for ( int i=0; i < employees.length; i++ )
if ( employeeIDs[ i ] == employeeID )
return employees[ i ];
return "ramesh";
Please help me. Thanks in advance

Is this the first time you are using the Universal Test Client? You first have to get to the EJB via either a create (for a Session Bean) or a create or finder method for an entity bean. Once you have the EJB, it should show you all the available methods and when you select one, it should give you the text box to enter the parameters. How far are you getting in the process? By the way, methods have to be defined in the remote or local interface for the UTC to show them.
This has nothing to do with the UTC but why is your getEmployeeName method throwing a CreateException?

Weblogic server 10.0 MP2 version compatibility with EJB3.0

Is it ok to use EJB3.0 in 10.0 MP2 ?
Are there any pitfalls or problems with EJB3.0 implementation with webloigc 10.0 MP2 version?
Currently we are using weblogic 10.0 MP2 version and planning to use EJB3.0 for one of our projects.
Do we still need to go to weblogic 10.3 for using EJB 3.0 or can we stick with webloigc 10.0 MP2 version
As per weblogic 10.0 documentation EJB3.0 is supported and JDK version used is 1.5. - http://docs.oracle.com/cd/E13222_01/wls/docs100/pdf/notes.pdf
Thanks
Deena

Hi Anup,
Maybe you should be a bit more specific about what you want to do. Coherence is just Java and has been supported WebLogic for years in the same way most other third-party Java libraries and APIs are. I first started using Coherence about four or five years ago with WebLogic 8.
JK

Unable to find ejb-jar with uri X.jar in ear at c:/Y/split_src

Stack trace is below, but the ejb does exist at the location that the FileNotFoundException states. I've checked that application.xml, org.eclipse.wst.common.component both have the correct name for this dependency.
java.lang.Exception: Exception received from deployment driver. See Error Log view for more detail.
at oracle.eclipse.tools.weblogic.server.internal.DeploymentProgressListener.watch(DeploymentProgressListener.java:190)
at oracle.eclipse.tools.weblogic.server.internal.WlsJ2EEDeploymentHelper.deploy(WlsJ2EEDeploymentHelper.java:506)
at oracle.eclipse.tools.weblogic.server.internal.WeblogicServerBehaviour.publishWeblogicModules(WeblogicServerBehaviour.java:1466)
at oracle.eclipse.tools.weblogic.server.internal.WeblogicServerBehaviour.publishToServer(WeblogicServerBehaviour.java:898)
at oracle.eclipse.tools.weblogic.server.internal.WeblogicServerBehaviour.publishOnce(WeblogicServerBehaviour.java:686)
at oracle.eclipse.tools.weblogic.server.internal.WeblogicServerBehaviour.publish(WeblogicServerBehaviour.java:539)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:774)
at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:3153)
at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:345)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Caused by: weblogic.application.ModuleException:
at weblogic.ejb.container.deployer.EJBModule.init(EJBModule.java:334)
at weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:167)
at weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:312)
at weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:325)
at weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:378)
at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:648)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191)
at weblogic.application.internal.EarDeployment.prepare(EarDeployment.java:59)
at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:154)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:60)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:208)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:98)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:747)
at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1216)
at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:250)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:159)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:171)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:46)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused by: java.io.FileNotFoundException: Unable to find ejb-jar with uri ***.jar in ear at C:\***\split_src
at weblogic.ejb.spi.EJBJar.<init>(EJBJar.java:81)
at weblogic.ejb.container.deployer.EJBModule.buildClassFinder(EJBModule.java:201)
at weblogic.ejb.container.deployer.EJBModule.init(EJBModule.java:313)

Hi Ten,
FYI, just by placing the ejb jar inside EAR project it will not be picked up for deployment. The EJB module has to be defined on EAR Module Assembly, and the steps are:
> EAR Project | Properties, Deployment Assembly - Add EJB module
NOTE: To verify the dependency you could try to export the EAR project to an .ear file. If the exported .ear file bundles ejb jar then deployment should work fine.
As far as the deployment mode, OEPE supports WebLogic Split-source (default) and Exploded archive. In the default split-source mode, the .beabuild.txt contains the mapping to the actual files whereas in exploded archive the files are copied over to deployment staging location.
Steps to modify deployment mode:
> In the server view, right click on server configuration | Properties, select WebLogic | Publishing
Please make sure the ejb module is defined appropriately and let me know if this resolves the issue.
Thanks,
Ram

Unable to publish - Unable to find ejb-jar with uri itr-ejbs.jar in ear

I'm using Weblogic 10.3.4 with Eclipse Juno before i was with Eclipse Galileo. Since the update i'm not able to publish my ear anymore.
I search on the internet the explanation of this stacktrace but i don't find a understandable answer so i ask to you :D
<5 oct. 2012 12 h 30 CEST> <Error> <Deployer> <BEA-149265> <Failure occurred in the execution of deployment request with ID '1349433008242' for task '0'. Error is: 'weblogic.application.ModuleException: '
weblogic.application.ModuleException:
     at weblogic.ejb.container.deployer.EJBModule.init(EJBModule.java:334)
     at weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:167)
     at weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:285)
     at weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:298)
     at weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:330)
     Truncated. see log file for complete stacktrace
Caused By: java.io.FileNotFoundException: Unable to find ejb-jar with uri itr-ejbs.jar in ear at D:\dev\workspaces\.metadata\.plugins\org.eclipse.core.resources\.projects\itr-ear\beadep\citron_domain\itr-ear\split_src
     at weblogic.ejb.spi.EJBJar.<init>(EJBJar.java:81)
     at weblogic.ejb.container.deployer.EJBModule.buildClassFinder(EJBModule.java:201)
     at weblogic.ejb.container.deployer.EJBModule.init(EJBModule.java:313)
     at weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:167)
     at weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:285)
     Truncated. see log file for complete stacktrace
>
<5 oct. 2012 12 h 30 CEST> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating deploy task for application 'itr-ear'.>
<5 oct. 2012 12 h 30 CEST> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException:
     at weblogic.ejb.container.deployer.EJBModule.init(EJBModule.java:334)
     at weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:167)
     at weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:285)
     at weblogic.application.internal.flow.InitModulesFlow.initModules(InitModulesFlow.java:298)
     at weblogic.application.internal.flow.InitModulesFlow.prepare(InitModulesFlow.java:330)
     Truncated. see log file for complete stacktrace
Caused By: java.io.FileNotFoundException: Unable to find ejb-jar with uri itr-ejbs.jar in ear at D:\dev\workspaces\.metadata\.plugins\org.eclipse.core.resources\.projects\itr-ear\beadep\citron_domain\itr-ear\split_src
     at weblogic.ejb.spi.EJBJar.<init>(EJBJar.java:81)
     at weblogic.ejb.container.deployer.EJBModule.buildClassFinder(EJBModule.java:201)
     at weblogic.ejb.container.deployer.EJBModule.init(EJBModule.java:313)
     at weblogic.application.internal.flow.ModuleListenerInvoker.init(ModuleListenerInvoker.java:167)
     at weblogic.application.internal.flow.InitModulesFlow.initModule(InitModulesFlow.java:285)
     Truncated. see log file for complete stacktrace
>Thank You

Hi,
It seems one of your ejb jar is missing from the current file location.
D:\dev\workspaces\.metadata\.plugins\org.eclipse.core.resources\.projects\itr-ear\beadep\citron_domain\itr-ear\split_src
you can make it manually copied to this location and build the project again so that it can able to deploy propertly.
Now one more thing you can do open a ticket with oracle support for better assistance.
Regards,
Kal

DOWN TIME WITH OPS

제품 : ORACLE SERVER
작성날짜 : 1995-04-13
Subject : DOWN TIME With OPS
I can only answer in a generic format. First, to understand how long fail
over will take, you must first understand the different operations that
takes place on fail over. My short answer would be, no, a 5 second average
down time is not feasible. My long answer is, it depends:
1) How long does it take for the other node(s) to realize that a node in
the cluster is down?
2) How long it takes to "remaster" the locks?
3) How long does it take for Oracle to perform instance recovery?
All of these play a part on how long fail over will take. My testing on fail over
has been focused on Pyramid's, but I believe it should be the same.
#1 is a tunable parameter - how often do you want each node in the cluster
to send a heart beat across to the other nodes? On our machines, it's
     set to 20 seconds before cluster rebuild and remastering of locks
     occur if a node goes down.
#2 Only takes minutes at most. I've been testing remastering of locks any
     where between 1000 locks -> 200,000 locks and worst case scenario
     (remastering all 200,000 locks) has only taken less than 4 minutes.
Setting gc_db_locks = 1000 only took seconds to remaster the locks.
#3 is probably the most time consuming. It's really dependent upon how much
     redo has been generated and I don't have any timing statistics on
     this.
A few things that we need to realize is that not all the locks may need to be
remastered - only the locks which were found "dubious" so the timing
statistics I gave on that are worst case scenario's for remastering locks.
Also, there's a possibility of absolutely no wait time if the data block
you're trying to access is mastered by a node which is up and running.

제품 : ORACLE SERVER
작성날짜 : 1995-04-13
Subject : DOWN TIME With OPS
I can only answer in a generic format. First, to understand how long fail
over will take, you must first understand the different operations that
takes place on fail over. My short answer would be, no, a 5 second average
down time is not feasible. My long answer is, it depends:
1) How long does it take for the other node(s) to realize that a node in
the cluster is down?
2) How long it takes to "remaster" the locks?
3) How long does it take for Oracle to perform instance recovery?
All of these play a part on how long fail over will take. My testing on fail over
has been focused on Pyramid's, but I believe it should be the same.
#1 is a tunable parameter - how often do you want each node in the cluster
to send a heart beat across to the other nodes? On our machines, it's
     set to 20 seconds before cluster rebuild and remastering of locks
     occur if a node goes down.
#2 Only takes minutes at most. I've been testing remastering of locks any
     where between 1000 locks -> 200,000 locks and worst case scenario
     (remastering all 200,000 locks) has only taken less than 4 minutes.
Setting gc_db_locks = 1000 only took seconds to remaster the locks.
#3 is probably the most time consuming. It's really dependent upon how much
     redo has been generated and I don't have any timing statistics on
     this.
A few things that we need to realize is that not all the locks may need to be
remastered - only the locks which were found "dubious" so the timing
statistics I gave on that are worst case scenario's for remastering locks.
Also, there's a possibility of absolutely no wait time if the data block
you're trying to access is mastered by a node which is up and running.

EJB Timer Services - timeout overlapping

Hi,
I have this question:
What should happen if the @Timeout method spends more time in working
something than the timer expiration time?
For example:
EJB timer is created with interval (expiration time) every 3 minutes. But for some reason the EJB binded to this timer is spending 4 minutes to process a timer notification. What happens with the next incoming timer notification?
Is it skipped or blocked? What happens with the method annotated as @Timeout?
Thanks!

Hi Fellipe,
This case isn't explicitly mentioned in the spec since the expectation is that the processing
time for the timeout would be much shorter than the interval itself. The design center for the
EJB Timer Service is to handle long-lived business processes so the spec examples for
timeouts are on the order of hours or days, even though the actual type in the API is
milliseconds. Many developers have expressed interest in support for finer-grained
timeouts and even cron-like functionality. The issue you raise would be an important one
to address in the scope of those EJB Timer Service additions.
Having said all that, the implementation in the Java EE SDK will not deliver a subsequent
timeout for the same timer until the previous one has completed.
--ken

Passivation EJB statefull with PersistenceContextType.EXTENDED in WLS 12c

Hi guys,
I have one web app with some EJB stateful working under Weblogic 12c.
A snippet of code:
public abstract class CommonHibernateDao<T extends AbstractModel, K extends Serializable> {
     private static final Logger LOGGER = LoggerFactory.getLogger(GenericHibernateDao.class);
     @PersistenceContext(type = PersistenceContextType.EXTENDED)
     protected transient EntityManager em;
     protected transient Session session;
     @SuppressWarnings("unused")
     private Class<T> persistentClass;
// common method like save delete...
@Stateful(name = "myDao")
public class MyDaoImpl extends CommonHibernateDao<Pojo, Serializable> implements MyDao, Serializable {
// methods with specific querys
In Glassfish 3.1.2 works fine, but in Weblogic 12c not.
What is happened?
When in Weblogic 12c the passivation the EJB throw one exception:
Message: <BEA-010024> <Error occurred during passivation: java.io.NotSerializableException: weblogic.persistence.ExtendedPersistenceContextWrapper
Stack: at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1164)
     at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
     at java.util.HashSet.writeObject(HashSet.java:267)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
     at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1469)
     at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
     at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
     at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
     at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
     at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
     at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
     at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
     at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
     at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
     at weblogic.ejb.container.swap.PassivationUtils.write(PassivationUtils.java:101)
     at weblogic.ejb.container.swap.DiskSwap.write(DiskSwap.java:173)
     at weblogic.ejb.container.manager.StatefulSessionManager.swapOut(StatefulSessionManager.java:1582)
     at weblogic.ejb.container.cache.LRUCache.put(LRUCache.java:149)
     at weblogic.ejb.container.manager.StatefulSessionManager.create(StatefulSessionManager.java:1246)
     at weblogic.ejb.container.manager.StatefulSessionManager.createBean(StatefulSessionManager.java:1313)
     at weblogic.ejb.container.internal.StatefulEJBLocalHomeImpl.createBeanAndReturnPK(StatefulEJBLocalHomeImpl.java:112)
     at weblogic.ejb.container.internal.StatefulSessionBeanReferenceImpl.getBusinessObject(StatefulSessionBeanReferenceImpl.java:39)
     at com.oracle.injection.integration.EjbDescriptorAdapter$EjbInstanceManagerAdapter.getEjbInstance(EjbDescriptorAdapter.java:236)
     at com.oracle.injection.provider.weld.WeldEjbServicesAdapter.resolveEjb(WeldEjbServicesAdapter.java:45)
     at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:406)
     at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:69)
     at org.jboss.weld.bean.SessionBean.create(SessionBean.java:293)
     at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:61)
     at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:630)
     at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:691)
     at org.jboss.weld.injection.ParameterInjectionPoint.getValueToInject(ParameterInjectionPoint.java:120)
     at org.jboss.weld.injection.MethodInjectionPoint.getParameterValues(MethodInjectionPoint.java:217)
     at org.jboss.weld.injection.MethodInjectionPoint.invoke(MethodInjectionPoint.java:111)
     at org.jboss.weld.util.Beans.callInitializers(Beans.java:712)
     at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:701)
     at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1$1.proceed(ManagedBean.java:156)
     at com.oracle.injection.provider.weld.WeldInjectionServicesAdapter.aroundInject(WeldInjectionServicesAdapter.java:88)
     at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:45)
     at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget$1.work(ManagedBean.java:152)
     at org.jboss.weld.bean.ManagedBean$FixInjectionPoint.run(ManagedBean.java:126)
     at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.inject(ManagedBean.java:148)
     at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:285)
     at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:61)
     at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:630)
     at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:657)

I got exactly the same issue with Weblogic 11g (10.3.6)
Could anybody take a look ?

EJB-QL with Date parameter

Hi All,
I have used the follwing EJB-QL with java.sql.Date as one of the parameter.
<query-method>
<method-name>findByLeaveEmpTypeDateStatus</method-name>
<method-params>
<method-param>java.lang.Integer</method-param>
<method-param>java.lang.Integer</method-param>
<method-param>java.sql.Date</method-param>
<method-param>java.lang.String</method-param>
</method-params>
</query-method>
<ejb-ql>
<![CDATA[select object(o) from LeaveBean o where o.leaveId = ?1
            and o.empTypeId = ?2 and o.createdDate = ?3 and o.status = ?4]]>
</ejb-ql>
The server log throws the following exception.
Test Name : tests.ejb.entity.ejbql.EjbQLFromCmpEntityDescriptor
Test Assertion : EJB 2.0 Spec Chapter 10 Container managed persistent
queries should comply with specification in its sytax and semantic rules
Test Description : Error: [ select object(o) from LeaveBean o where
o.leaveId = ?1 and o.empTypeId = ?2 and o.createdDate = ?3 and o.status = ?4 ]
has parsing error(s)
Exception occured : [Invalid type for expression (o.createdDate = ?3)
EJB QL statement : 'select object(o) from LeaveBean o where o.leaveId = ?1
and o.empTypeId = ?2 and o.createdDate = ?3 and o.status = ?4'
EJB QL method    : public abstract LeaveLocal LeaveLocalHome.findByLeaveEmpTypeDateStatus
(java.lang.Integer,java.lang.Integer,java.sql.Date,java.lang.String)
throws javax.ejb.FinderException
All the ejb-ql statements with Date as parameter only are throwing the above exception.
Instead of java.sql.Date, I have tried with Timestamp and Long, but the same exception throws.
I am using Oracle as my DB.
The same application with Date as parameter works fine with Weblogic and JBoss.
--Muthu.

We are having the same problem: We have timestamps in the database and the ejbql is this:
SELECT Object(e) FROM EstimateOrder e WHERE e.idDistributor = ?1 and e.ordDateEntered > ?2 and e.ordDateEntered < ?3
The verifier gives this error:
Exception occured : [Invalid type for expression (e.ordDateEntered > ?2)
Can timestamps be used as input params in ejbql and the used in comparisons? We tried the "between" also with the same results.

EJB timer info in persistent store

Is it possiblle to configure WL 10.3.5 so that ejb timer information is stored into JDBC persistent store instead of the default file store?
Where can I find documentation about that ?
Or is it allowed in cluster configurations only ?
Thanks

Is it possiblle to configure WL 10.3.5 so that ejb timer information is stored into JDBC persistent store instead of the default file store?
Where can I find documentation about that ?
Or is it allowed in cluster configurations only ?
Thanks

WebLogic 12.1.3 Cluster EJB Timer with filesystem

Similar Messages

Maybe you are looking for