Using TableLocking API in Stateless Session Bean through WD application
Hi All,
We have develpoed a webDynpro application which involved Jav Dictionary Table.
We have given UI for Creation, Updation and Deletion of the table.For database connection we have used Stateless Session Bean.
we have the requirement of Locking the Table record when one user is either editing or deleting the record of Table from UI, so any other user cannot update or delete the same record.
To implement the above functionality, we have used TableLocking API with lifetime as userSession in the Stateless Session Bean to acquire a Lock for particular record.
With lifetime as usersession the record should get unLocked automatically, if the session of application is expired and record is not unLocked Explicitly.
We are calling the Session Bean from Webdynpro application to acquire a lock, When the Dynpro application expires the locked record should get unlocked automatically as the lifetime is defined as usersession,But the record remains unlocked only even after expiration of the application sessionand deadlock occurs for that record.
So if anyone can suggest the solution for the above problem.
Or some other method to Lock Particular Record from application.
Thanks in advance.
Regards,
Shruti.
HI,
Can you resolve this issue?
I have the same scenary, could you give me some tips?
Thanks,
Freddy F
Similar Messages
-
How to use jta in toplink and stateless session bean EJB 3.0?
I have an application with techologies jsf,stateless session bean, adf, toplink
generated by toplink workbench.
In web side ı want to use two methods in stateless session bean which are updated
different tables. I call these methods in my page backing bean.
I also want to JTA in web side. My first methods is done correctly, but second method has an error. I wanto to rollback all transaction.
How can ı do that? with using JTA in Toplink...Yuichi
Did you manage to solve this? I'm doing something similar and seeing the same problem, although they're up to 7.3 SP7.
Any help greatly appreciated.
Lewis -
Transaction Management - App Module in Stateless Session Bean
Hi All,
We are using Application Module in local mode in a Stateless Session Bean. The application module gets the database connection from the datasource of the application server(Oracle 9iAS).
The problem that we are facing is as follows
- When a database update/insert is made using the Application Module and the ViewObject (and the underlying Entity Object), the changes are not being commited.
Please note that we are not using the ApplicationModule.getTransaction.commit() as it does not give us commit/rollback control from another Session Bean/UseCase. We instead are relying on the Container to manager the transaction and commit the database changes. But the container does not seem to refresh the changes to the database.
Q1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?
Any help in this matter would be greatly appreciated.
-Ankur SinhaQ1 - Is there a contract between the container and the application module that needs to be created so that the container managed-transaction and the application module work together ?For stateless beans you have to call postChanges in the business method for the changes to be applied to the db. For stateful beans bc4j we do that automatically just before the transaction ends.
Take a look at the following howto
http://otn.oracle.com/products/jdev/howtos/bc4j/ejbstateless_with_bc4j.html
In 9.0.3 you'll be able to create a stateless service bean declaritively.
dhiraj Hi dhiraj,
- I looked at the example but was not able to find the ContainerManagedTxnHandlerImpl class in the BC4J jars. Can you point me to the latest version of BC4J on technet ?. I already have JDeveloper 9.0.2
- Regarding your response, what do you mean by creating stateless service bean declaritively ?
Thanks,
Ankur -
Is it possible to restrict the object creation for stateless session beans
Hi,
Is it possible to restrict/fix the ejb object creation for stateless session beans in application server?
For example, i want to configure the application server ( am using JBOSS ) to create maximum of 10 session bean objects. and if any requests for the stateless session bean come, as application server has created 10 objects, the requests should be blocked.
Thanks in advance,
nvseenuYou can keep a counter in the application code. A static var won't work, but an entity and a consistent id should. This version would affect performance, but it would be portable to other app servers.
// ConstrainedBean.java
package unq.ejb;
import javax.ejb.Stateless;
import javax.ejb.CreateException;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import javax.persistence.PersistenceContext;
import javax.persistence.EntityManager;
@Stateless
public class ConstrainedBean implements Constrained {
final static int DEFAULT_COUNTERID = 1;
@PersistenceContext EntityManager em;
@PostConstruct
protected void init() throws CreateException {
ConstrainedBeanCounter counter =
em.find(ConstrainedBeanCounter.class, DEFAULT_COUNTERID);
if( counter == null ) {
counter = new ConstrainedBeanCounter();
counter.counterId = 1;
counter.counterValue = 0;
em.persist(counter);
if( counter.atMaximum() ) {
throw new CreateException("error attempting to create > 10 beans");
else {
counter.increment();
@PreDestroy
protected void destroy() {
ConstrainedBeanCounter counter = em.find(ConstrainedBeanCounter.class,
DEFAULT_COUNTERID);
counter.decrement();
public void doSomething() { System.out.println("doSomething()"); }
// ConstrainedBeanCounter.java
package unq.ejb;
import javax.persistence.Entity;
import javax.persistence.Id;
@Entity
public class ConstrainedBeanCounter implements java.io.Serializable
@Id public int counterId;
public int counterValue = 0;
public void increment() {
counterValue++;
public void decrement() {
counterValue--;
public boolean atMaximum() {
return counterValue > 9;
} -
Newbie: How do i use a stateless session bean in a backing bean?
I have a stateless session bean with a function 'getVoterList()'; how do i instantiate the bean and use it in from my managed bean?
I dont want to use seam; coz the stateless serrion bean/EJB is written by another developer and we cant updat eit now to use seam..
any tutorials? walk thrus or sample code?
thanks
illiI used a different method...
I used servicegen with only a.jar to create the ear.
I touch-ed my own application.xml to make it newer than the one already in the
newly created ear.
I used the ant <ear> task to add b.jar, c.jar, and application.xml to the ear.
Worked like a charm.
Mike
Bruce Stephens <[email protected]> wrote:
Hello,
See if Neal's answer here helps solve your problem using servicegen's
service element "IncludeEJBs" attribute:
http://newsgroups.bea.com/cgi-bin/dnewsweb?cmd=article&group=weblogic.developer.interest.webservices&item=2932&utag=
HTHs,
Bruce
kk wrote:
This is my situation.
I have an .ear file and in that i have several other .jar files whichare
inter-dependant, lets say
A.jar
B.jar
C.jar files
and i want to expose only A.jar as
webservice, how can i do that ?
Does WLS8.1 provided any way how to do that?
I Appreciate any suggestions and advices.
Thanks
kk -
Bean-managed stateless session bean can't roll back using JTA
I use weblogic6.1sp2 + jdk131
a stateless session bean must do 2 things:
insert a record to A table and delete another record in A table
this bean has the same structure as the example in
j2eetutorial/examples/src/ejb/teller
I use TxDataSource in weblogic
if delete fail, the roll back is run,but in database,
the insert record is STILL in A table.
any idea?make sure that your deployment descriptor says "transaction required".
Also, If the insert and delete are two different methods, the client must call these two methods in the same transaction scope. -
Transactional error when using JMS from stateless session bean
I get a transaction exception when committing a bean method responsible for sending to a JMS topic. This happens only occasionally when two separate threads invoke this method "at the same time".
The scenario:
Two separate threads running two different instances of a stateless session bean (slsb A). This ejb (slsb A) has an injected slsb B which is communicating with the the topic.
Both instances of slsb A are utilising the same instance of slsb B.
The CMT transactions for the two threads start in slsb A from methods with transaction attribute "RequiresNew". All nested methods are to other slsbs and have the transaction attribute "Required". The method in slsb B which sends the message is closing both the session and the connection to the topic.
I'm running Glassfish version 9.1_02 (build b04-fcs) and JMS implementation OpenMQ version 4.1.
Stacktrace (glassfish log):
[#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.resourceadapter.mqjmsra.outbound.connection|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|commitTransaction (XA) on JMSService:jmsdirect failed for connectionId:5754505514139844608 and onePhase:false due to unkown JMSService server error.|#]
[#|2008-09-09T13:00:40.515+0200|SEVERE|sun-appserver9.1|javax.enterprise.system.core.transaction|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe;commit;_RequestID=108e8418-71a6-4d8b-a94d-9e1edc885891;|JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation.|#]
[#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;SubscriptionBean;|EJB5018: An exception was thrown during an ejb invocation on [SubscriptionBean]|#]
[#|2008-09-09T13:00:40.531+0200|INFO|sun-appserver9.1|javax.enterprise.system.container.ejb|_ThreadID=18;_ThreadName=httpSSLWorkerThread-8080-1;|
javax.ejb.EJBException: Unable to complete container-managed transaction.; nested exception is: javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
javax.transaction.SystemException: org.omg.CORBA.INTERNAL: JTS5031: Exception [org.omg.CORBA.INTERNAL: vmcid: 0x0 minor code: 0 completed: Maybe] on Resource [commit] operation. vmcid: 0x0 minor code: 0 completed: No
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:321)
at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
at $Proxy130.requestNewSubscription(Unknown Source)
at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
at $Proxy129.requestNewSubscription(Unknown Source)
at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
IMQ broker log:
[09/Sep/2008:13:00:40 CEST] ERROR CommitTransaction: commit failed. Connection ID: 5754505514139844608, Transaction ID: 0:
com.sun.messaging.jmq.jmsserver.util.BrokerException: Unknown Transaction 0
at com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.commitTransaction(ProtocolImpl.java:630)
at com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.commitTransaction(IMQDirectService.java:1735)
at com.sun.messaging.jms.ra.DirectXAResource.commit(DirectXAResource.java:201)
at com.sun.jts.jtsxa.OTSResourceImpl.commit(OTSResourceImpl.java:114)
at com.sun.jts.CosTransactions.RegisteredResources.distributeCommit(RegisteredResources.java:795)
at com.sun.jts.CosTransactions.TopCoordinator.commit(TopCoordinator.java:2111)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:403)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:249)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1030)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:397)
at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3792)
at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3585)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1354)
at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1316)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:205)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:127)
at $Proxy130.requestNewSubscription(Unknown Source)
at com.abeldrm.kms.core.services.subscription.SubscriptionWSBean.requestNewSubscription(SubscriptionWSBean.java:94)
at sun.reflect.GeneratedMethodAccessor127.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1067)
at com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:176)
at com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2895)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3986)
at com.sun.ejb.containers.WebServiceInvocationHandler.invoke(WebServiceInvocationHandler.java:189)
at $Proxy129.requestNewSubscription(Unknown Source)
at sun.reflect.GeneratedMethodAccessor126.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.enterprise.webservice.InvokerImpl.invoke(InvokerImpl.java:81)
at com.sun.enterprise.webservice.EjbInvokerImpl.invoke(EjbInvokerImpl.java:82)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:146)
at com.sun.xml.ws.server.sei.EndpointMethodHandler.invoke(EndpointMethodHandler.java:257)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:93)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.enterprise.webservice.MonitoringPipe.process(MonitoringPipe.java:147)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:106)
at com.sun.xml.ws.tx.service.TxServerPipe.process(TxServerPipe.java:329)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.processRequest(CommonServerSecurityPipe.java:218)
at com.sun.enterprise.webservice.CommonServerSecurityPipe.process(CommonServerSecurityPipe.java:129)
at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:115)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:595)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:554)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:539)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:436)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:243)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:444)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:244)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:135)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.handlePost(Ejb3MessageDispatcher.java:113)
at com.sun.enterprise.webservice.Ejb3MessageDispatcher.invoke(Ejb3MessageDispatcher.java:87)
at com.sun.enterprise.webservice.EjbWebServiceServlet.dispatchToEjbEndpoint(EjbWebServiceServlet.java:226)
at com.sun.enterprise.webservice.EjbWebServiceServlet.service(EjbWebServiceServlet.java:155)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at com.sun.enterprise.web.AdHocContextValve.invoke(AdHocContextValve.java:114)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:87)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:272)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:637)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:568)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:813)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:341)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:263)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:214)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:265)
at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:106)
Have anyone any idea why this should fail?
Regards,
JonI would suggest opening a case with [email protected] FWIW, I recall seeing
something like this in WLS 6.0. I believe it is fixed in WLS 6.1
-- Rob
Chris Dupuy wrote:
> Btw, this occurs when I create an stateful session bean that ends up
> throwing an exception and setRollbackOnly() is called. From that point
> forward, my logs fill with this message.
>
> Chris
>
> "Chris Dupuy" <[email protected]> wrote in message
> news:[email protected]..
> > anyone know what this means, and what you can do about it?
> >
> >
> > <Error> <ConnectionManager> <atossd03> <cbeyondServer> <ExecuteThread:
> '14'
> > for queue: 'd
> > efault'> <> <> <000000> <Closing:
> 'weblogic.rjvm.t3.T3JVMConnection@488831'
> > because of: 'Server received a message over an uniniti
> > alized connection: 'JVMMessage from: 'null' to:
> >
> '5825313123619479267S:10.6.6.40:[8000,8000,8001,8001,8000,8001,-1]:cbeyond:c
> > beyond
> > Server' cmd: 'CMD_REQUEST', QOS: '101', responseId: '2', invokableId: '1',
> > flags: 'JVMIDs Not Sent, TX Context Not Sent', abbrev o
> > ffset: '204'''>
> >
> >
> >
-
Run servlet through stateless session bean
can any body help me about.........
how to run(execute or call) servlet through state less session bean.
i have developed servlet program, now i want to run that servlet from stateless session bean ,can any body help ,how to write the code for above oneHi
it can be possible if your session bean can call servlet through an protocol.
means you can create an URL or URL connection class and call it through http protocol.
i .e we can create URLConnetion ( HttpURLConnection ) object to that servlet from a session bean.
I hope this will help you some extent to solve your probs.
Thanks
Mrutyunjaya Tripathy -
Calling EJB 3.0 Stateless Session Bean
Dear all,
I created a stateless session bean with a hello world method on it. Now i want to call the method from a BeanDecorator class, through a getter metod. When i use the jndi lookup in my getter, i can call the helloWorld method without a problem. However, when i dont use the jndi lookup, and only use the @EJB annotation, i always get a nullpointer.
This is working:
InitialContext ic = new InitialContext();
test = (TestLocal)ic.lookup("test.be/ear~bd/LOCAL/TestBean/"+TestLocal.class.getName());
test.helloWorld()
This gives nullpointer:
@EJB
private TestLocal test;
test.helloWorld();
What is the correct way to consume session beans without having to explicitly code the jndi lookup?
Kind regards.Hi,
any annotation like this can be used only in "managed classes" like Session Beans, Servlets etc. Managed classes are those classes managed by the J2EE server. Managed here means, lifetime controlled by server.
You can find this in J2EE specification.
Frank -
How to get stateful and stateless session bean in second jsp
I create stateful session bean in the first jsp, then how can I get the stateful session bean in the second jsp? I find that somebody store the bean in HttpSession.
If I store the stateful session bean in HttpSession, then I can get it in the second jsp. My problem is that I can store the stateless session bean in HttpSession, and get it in the second jsp. Then, both stateful and stateless can maintain the state in the second jsp. What is the difference between stateful and stateless session bean in this case ?
I understand the definition of stateful and stateless session bean, but I'm confuse how to use session bean. Can anyone provide sample jsp to show difference of stateful and stateless? How the stateful session bean can maintain the state for the client?Greetings,
I create stateful session bean in the first jsp, then how can I get the stateful session bean in the
second jsp? I find that somebody store the bean in HttpSession.Which is the correct scope for sharing client-specific data when 'request' scope is insufficient.
If I store the stateful session bean in HttpSession, then I can get it in the second jsp. My problem is
that I can store the stateless session bean in HttpSession, and get it in the second jsp. Then, bothWhy is that a "problem"? Does your application not require the stateless bean to be shared? If so, then don't store the EJBObject reference in the session...
stateful and stateless can maintain the state in the second jsp. What is the difference betweenWhat do you mean by this exactly?..
stateful and stateless session bean in this case ?Statefulness of session beans is in regard to maintaining client state (er, in all cases). If your "stateless" bean is receiving information from the client (i.e. its caller) - either through a create method or a business method - and that information is available (retrievable from the bean) on subsequent method calls, then that bean is, in fact, stateful - regardless of how it is deployed.
I understand the definition of stateful and stateless session bean, but I'm confuse how to use
session bean.The correct question, it here seems, is "when" to use which type... Use a "stateful" bean when information about (from) the client (i.e. the caller) must be maintained across method calls of the bean. Use a "stateless" bean for general business methods that do not depend on "prior knowledge" of the client (i.e. the caller).
Can anyone provide sample jsp to show difference of stateful and stateless? How the statefulA "sample JSP" would yield nothing additional... The semantics of calling, using, and "persisting", bean references are always the same - regardless of type or class. However, the reason(s) for using one over the other depends entirely on the needs of your application.
session bean can maintain the state for the client?I recommend that you spend more time learning about EJBs generally. In particular, it seems you require more fundamental understanding of their scope and lifecycle. Refer to sections 4, 6, and 7 of the EJB 2.0 Specification.
Regards,
Tony "Vee Schade" Cook -
Not be able to obtain a transacted session within stateless session bean
I need some assistance on creating a transacted session. For some reason while within a stateless session bean, I am unable to create a transacted session even though I'm specifying to create the transacted queue session. Can anyone provide any assistance to me on this? It would be much appreciated.
Here is the code snippets involved with the problem:
Code snipet from ejb-jar.xml:
<session>
<display-name>Initial Request</display-name>
<ejb-name>InitialRequestBean</ejb-name>
<ejb-class>com.raytheon.rds.jms.InitialRequestBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
Code from stateless session bean:
static Logger logger;
private QueueConnectionFactory connectionFactory;
private SessionContext sc;
private Queue requestQueue;
public String processRequest(String msgBody)
logger.log(Level.INFO, "In processRequest(String).", msgBody);
QueueConnection con = null;
QueueSession session = null;
QueueSender sender = null;
TextMessage message = null;
String messageID = null;
QueueReceiver receiver = null;
TemporaryQueue replyQueue = null;
boolean transacted = false;
try
//Create the infrastructure (ie. The connection & the session)
logger.log(Level.FINE, "Creating connection");
con = connectionFactory.createQueueConnection();
logger.log(Level.FINE, "Creating session");
session = con.createQueueSession(true, Session.AUTO_ACKNOWLEDGE);
//Note: This line above was changed in all possible permutation and still didn't work such as using Session.SESSION_TRANSACTED
transacted = session.getTransacted();
logger.log(Level.FINE, "Is session transacted? : " + transacted);
//Note: This line above is constantly saying false
//Now first, setup the temporary reply queue and its listener
replyQueue = session.createTemporaryQueue();
logger.log(Level.FINE, "Creating receiver/consumer");
receiver = session.createReceiver(replyQueue);
con.start();
//Now create the requestor that will make the request message and put it on the request queue
logger.log(Level.FINE, "Creating Requestor/Producer");
sender = session.createSender(requestQueue);
//Now create the message and make sure that you put the "JMSReplyTo" property to the temporary response queue we just created
message = session.createTextMessage();
message.setJMSReplyTo(replyQueue);
logger.log(Level.FINE, "Created message: " + message.getJMSMessageID());
//Now add the actual info you want to send
message.setText(msgBody);
//Now send the message
logger.log(Level.INFO, "Sending message: " + message.getText());
sender.send(message);
//Now wait until we get a response
logger.log(Level.FINE, "Waiting for the response message");
Message responseMsg = receiver.receive(20000); //Toggle the "0" to specify timeout in millisectionds
//Process the message
logger.log(Level.FINE, "Processing the response message");
if(null != responseMsg)
logger.log(Level.FINE, "responseMsg is : " + responseMsg.toString());
messageID = processMessage(responseMsg);
logger.log(Level.FINE, "Response is : " + messageID);
//close the connection
logger.log(Level.FINE, "Stopping the connection");
con.stop();
catch (Throwable t)
// JMSException could be thrown
logger.log(Level.SEVERE, "Exception Thrown in sendRequest: ", t);
sc.setRollbackOnly();
finally
//Close the sender
if (sender != null)
try
logger.log(Level.FINE, "Closing the sender");
sender.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the sender to the request queue: ", e);
else
logger.log(Level.FINE, "Sender is already closed.");
//Close the receiver
if (receiver != null)
try
logger.log(Level.FINE, "Closing the receiver");
receiver.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the receiver to the request queue: ", e);
else
logger.log(Level.FINE, "Receiver is already closed.");
//Close the session
if (session != null)
try
logger.log(Level.FINE, "Closing the session");
session.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the session to the request queue: ", e);
else
logger.log(Level.FINE, "Session is already closed.");
//Close the connection
if (con != null)
try
logger.log(Level.FINE, "Closing the connection");
con.close();
catch (JMSException e)
logger.log(Level.WARNING, "JMSException Thrown when trying to close the connection to the reply queue: ", e);
else
logger.log(Level.FINE, "Connection is already closed.");
return messageID;
}I found the answer through lots of painful searching.
http://blogs.sun.com/fkieviet/entry/request_reply_from_an_ejb
This weblog from Frank Kieviet from a sun blog explains what's happening behind the scenes.
Then I proceeded to create a Bean-Managed Transaction out of my EJB, which is using EJB 3.0. This requires the tag:
@TransactionManagement(value= TransactionManagementType.BEAN)
Note: I got this information from http://download.oracle.com/docs/cd/B31017_01/web.1013/b28221/servtran001.htm#BAJIBAFF
Then I just added the code specified in Frank's blog and everything is working now. The main portion of the code looks like this now:
//begin the user transaction
ctx.getUserTransaction().begin();
//Create the infrastructure (ie. The connection & the session)
logger.log(Level.FINE, "Creating connection");
con = connectionFactory.createQueueConnection();
//Create the session
logger.log(Level.FINE, "Creating session");
session = con.createQueueSession(false, Session.SESSION_TRANSACTED);
transacted = session.getTransacted();
logger.log(Level.FINE, "Is session transacted? : " + transacted);
//Now create the sender that will make the request message and put it on the request queue
logger.log(Level.FINE, "Creating Sender");
sender = session.createSender(requestQueue);
//Now create the message
message = session.createTextMessage();
//Now add the actual info you want to send
message.setText(msgBody);
logger.log(Level.FINE, "Created message: " + message.getJMSMessageID());
//Now first, setup the temporary reply queue and its listener
replyQueue = session.createTemporaryQueue();
if(null != replyQueue)
logger.log(Level.FINE, "Created temporary queue: " + replyQueue.getQueueName());
else
logger.log(Level.FINE, "Temporary Queue could not be created.");
//make sure that you put the "JMSReplyTo" property to the temporary response queue we just created
message.setJMSReplyTo(replyQueue);
//Now send the message
logger.log(Level.INFO, "Sending message: " + message.getText());
sender.send(message);
//Now start the connection
logger.log(Level.FINE, "Starting the connection");
con.start();
//commit the changes
ctx.getUserTransaction().commit();
ctx.getUserTransaction().begin();
//Create the receiver
logger.log(Level.FINE, "Creating Receiver");
receiver = session.createReceiver(replyQueue);
//Now wait until we get a response
logger.log(Level.FINE, "Waiting for the response message");
Message responseMsg = receiver.receive(20000); //Toggle the "0" to specify timeout in millisectionds
//Process the message
logger.log(Level.FINE, "Processing the response message");
if(null != responseMsg)
logger.log(Level.FINE, "responseMsg is : " + responseMsg.toString());
else
logger.log(Level.FINE, "No response came back.");
messageID = processMessage(responseMsg);
logger.log(Level.FINE, "Response is : " + messageID);
logger.log(Level.FINE, "Transaction is complete");
//commit the changes
ctx.getUserTransaction().commit(); -
We are writing a J2EE application and using Weblogic 5.1 on Unix machine. We are
considering writing some Stored Procedures or Triggers on Oracle DBMS. Hence our
Stateless Session Beans / Data Access Objects (DAOs) would be calling those stored
procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These Data
Access Objects are running under the umbrella of a Stateless Session Beans). We
are using WebLogic's Connection Pooling.
Our question is: Would we get reliable rollbacks from our stored procedures. I
mean would the Transaction Management process of the EJB container work. Remember
the SQL is written in the Database (Oracle in this case) in the form of Stored
Procedures / Triggers through PL/SQL.
Any ideas or tips would help.
I would agree with Cameron Purdy. Be very cautious to use Oracle specific
Triggers / Stored Procedures. Consider following, (apart from what he said):
1. Unreliable behaviour of the Oracle JDBC drivers, specially 8.1.6 family..
(You may visit the Oracle's web site and see the newsgroups for the JDBC drivers).
This is enough of a reason to stop right there.
However for interest sake you may consider following issues:
2. By use of Oracle specific Triggers / SPs the application will not be portable.
Vendor Lock In. Remember your choice for J2EE compliant Server (WebLogic in this
case). The whole purpose would be defeated by going for this option.
3. There are issues related to the extensibility of the application. I have
my reservations and would hold my breath on two phase commit protocol transactions
being reliable in this scenario.
Have fun...
Terry
"Cameron Purdy" <[email protected]> wrote:
>Yes, the work performed by the SPs and the triggers would be in the same
>tx.
>
>What would NOT work is if the data has been read into WebLogic and then
>it
>gets affected by a trigger or SP on the RDBMS, the data in WebLogic is
>not
>automatically re-read within that same tx so you need to be careful.
>
>Peace,
>
>--
>Cameron Purdy
>Tangosol Inc.
>Tangosol Coherence: Clustered Coherent Cache for J2EE
>Information at http://www.tangosol.com/
>
>
>"Ahmad" <[email protected]> wrote in message
>news:[email protected]...
>>
>> We are writing a J2EE application and using Weblogic 5.1 on Unix machine.
>We are
>> considering writing some Stored Procedures or Triggers on Oracle DBMS.
>Hence our
>> Stateless Session Beans / Data Access Objects (DAOs) would be calling
>those stored
>> procedures, which would reside on Oracle 8.1.7 (on Windows 2000). (These
>Data
>> Access Objects are running under the umbrella of a Stateless Session
>Beans). We
>> are using WebLogic's Connection Pooling.
>> Our question is: Would we get reliable rollbacks from our stored
>procedures. I
>> mean would the Transaction Management process of the EJB container
>work.
>Remember
>> the SQL is written in the Database (Oracle in this case) in the form
>of
>Stored
>> Procedures / Triggers through PL/SQL.
>> Any ideas or tips would help.
>
>
-
EJBRemove on stateless session bean
I would like to create a stateless session bean that loads data from
the DB when it is created. Since the data being loaded is subject to
change, I'd like to make sure that the stateless session bean is
"destroyed" at least once every x seconds. Is it possible to do that
through the deployment descriptor ?
Mathieu
(No need to tell me that this bean might use data that is not in sync
with the db, I know that)I still do not understand what is wrong with read-only entity beans - it
sounds like they do exactly what you want, automatically.
Also, stateless session beans have no identity and remove() doesn't do
anything.
Mathieu <[email protected]> wrote:
Let me be more specific:
I need to access some data (=> several rows from the DB) very
frequently. I don't need that data to be always up-to-date, I just
need to make sure that it is refreshed once in a while. Therefore, I
prefer to have to retrieve one session bean than X entity beans (one
per row). The argument about the expense of destroying the bean
doesn't seem to me to be a valid one because if I use read-only entity
beans, I would expect them to be destroyed and reloaded as well. And
furthermore, I don't understand why it would be costly to destroy such
a stateless session bean.
"David Shiffman" <[email protected]> wrote in message news:<3c130d6a$[email protected]>...
Agree. Even if it's possible to destroy your stateless bean on a timely basis this
approach is not the best for a number of reasons including the expense of destroying
the bean...
Dimitri Rakitine <[email protected]> wrote:
Hrm. Why don't you use ReadOnly entity beans for this purpose ?
Mathieu <[email protected]> wrote:
I would like to create a stateless session bean that loads data from
the DB when it is created. Since the data being loaded is subject to
change, I'd like to make sure that the stateless session bean is
"destroyed" at least once every x seconds. Is it possible to do that
through the deployment descriptor ?
Mathieu
(No need to tell me that this bean might use data that is not in sync
with the db, I know that)--
Dimitri
Dimitri -
Stateless session beans and idle timeouts (weblogic 10.3.1)
Need clarification about stateless session beans and the idle-timeout-seconds setting.
Situation is this – we have a process that is timing out due to an API call to a very slow Authentication server.
I am trying to resolve this with a code change, but need to further other understand what the server is actually doing.
We have a session bean which calls another which is calling a util class that does all the work and returns the results back up to the initial session bean. I have left out the ejbName in these examples (it’s irrelevant here).
Example:
SessionBean1 // basically called just once a day
@Session(defaultTransaction = Constants.TransactionAttribute.SUPPORTS,
enableCallByReference = Constants.Bool.TRUE,
type = Session.SessionType.STATELESS,
transTimeoutSeconds = "0",
initialBeansInFreePool = "0",
maxBeansInFreePool = "20")
Methods
@RemoteMethod() public boolean getUserList(String adminGroup) {
Map usrList = getUserList(adminGroup);
Private Map getUserList(String adminGroup) {
return SessionBean2.getUsers(adminGroup);
SessonBean2
@Session(defaultTransaction = Constants.TransactionAttribute.SUPPORTS,
enableCallByReference = Constants.Bool.TRUE,
type = Session.SessionType.STATELESS,
transTimeoutSeconds = "0",
initialBeansInFreePool = "3",
maxBeansInFreePool = "20")
Method
@RemoteMethod() public Map getUsers(String adminGroup) throws RemoteException {
return javaUtilClass.getUsers(adminGroup);
JavaUtilClass
Method
public Map getUsers(String adminGroup) throws RemoteException {
// This is where the work happens, calling the Authentication server to get a complete
// list of users for an admin group. When the user list is around 1500 entries, this can
// take an hour. Did I mention this server is very slow? It’s about this threshold of 1500
// that causes the timeout.
return Map of users
First thought, just bump the idle-timeout-seconds setting for the session beans (from the default 600), but that would be a temporary solution until the user list grew larger.
Second thought, refactor the call to the Authentication Server API to get the user list in blocks of data (say 400 at a time) and decreasing the call/response time between the method getUsers and the API call. This would still occur in the JavaUtilClass, so I am unsure this would make a difference. The session beans would still be idle and subject to timeout, correct?
Would setting initialBeansInFreePool to 1 in SessionBean1 make any difference?
Or should I be looking at replicating the re-factored method from the JavaUtilClass in SessionBean1 where the user list is being used so that the API calls come back to it and keep it 'active'?
Thanks for any advice you could give me on this.Hi
regarding timeouts, there are two ways:
1.- Changing the settings in the JTA WebLogic domain , called "Timeout Seconds". This will affect globally to all EJB deployed in the domain.
or
2.- Specified directly in the bean with a weblogic annotation, like this:
@TransactionTimeoutSeconds(value = 300)I hope this will help you.
Regards.
Felipe -
Transaction not rolling back in stateless session bean
Hi,
I am facing a problem...
I have one stateless session bean which does multiple updates in SYBASE database.I
am using non-transactional datasource. Bean calls a method of data access obejct
whcih internally calls more than one one mehtod to update different tables.If
any of update fails then I am explicitly thorwing EJBException. Still it is not
rolling back.
I have one more application where similar situation is there but only difference
is that there we have Entity bean and updates are being done through store method.
In that case with same datasource it is rolling back perfectly.
I have tried with transactional datasource as well but it didn't work.Then I tried
to put setAutoCommit(false) in my connection class which gives me connection.But
then it is not allowing me to enter into my application.
In deployment descriptor for both the beans transaction attribute is required
for all methods.
Regards.
Rahul.
Hi,
I am facing a problem...
I have one stateless session bean which does multiple updates in SYBASE database.I
am using non-transactional datasource. Bean calls a method of data access obejct
whcih internally calls more than one one mehtod to update different tables.If
any of update fails then I am explicitly thorwing EJBException. Still it is not
rolling back.
I have one more application where similar situation is there but only difference
is that there we have Entity bean and updates are being done through store method.
In that case with same datasource it is rolling back perfectly.
I have tried with transactional datasource as well but it didn't work.Then I tried
to put setAutoCommit(false) in my connection class which gives me connection.But
then it is not allowing me to enter into my application.
In deployment descriptor for both the beans transaction attribute is required
for all methods.
Regards.
Rahul.
Maybe you are looking for
-
Problem with examples in dbxml 2.4.13
I downloaded a time ago dbxml 2.4.13 for windows (msi file) I tried to compile the helloworld example. That went fine, but when I run it, I it get always a memory exception problem. Unhandled exception at 0x7c812aeb in dbxmltest.exe: Microsoft C++ ex
-
I'm not a Mac user so please bear with me. I am helpdesk for a business and I am have issues with our G5. About a month ago our user went to sign on and when it came up the the spinning rainbow and all that appeared was the question mark on the bar i
-
Purchased Motion backgrounds to use in FCE - not working correctly!
Hi there, Perhaps someone can help me. I ordered some motion backgrounds from actionbacks.com and have been trying to use them in FCE. These backgrounds are meant to loop seamlessly when they are stacked side by side... When i drag one into the timel
-
PnPDriverImportError - CS5.5 clean install on Win7/64
Hello: Pretty new here, so if this belongs somewhere else (Acrobat forum?), please feel free to move. And, I am a self-taught, low-end, home user of mostly Acrobat and PS, so please keep any assistance relatively simple. Problem: "Adobe PDF Printer"
-
When you delete a component from a jspx page, it does not delete it from the PageDef.