Are You Recruiter/Hiring Manager?
Cloud-based Candidate Screening | Online Tests
PMP 1600 Questions
PMP 1600 Questions
1600 PMP mock questions 1400 CAPM mock questions 800 SCJP 6 mock questions 600 OCAJP 7 mock questions 590 OCPJP 7 mock questions 556 SCWCD 5 mock questions 500 OCEJWCD 6 mock questions pdfDownload (java,struts, hibernet etc)

Tutorial Home

Hibernate

  • Advantage of Hibernate over JDBC
  • Hibernate Setup with an web Application
  • First Hibernate Application
  • Hibernate mapping with Database TABLE
  • Hibernate Data Type-Java Data Type - SQL Data Type mapping
  • One to Many Relation in Hibernate
  • One to Many Relation in Hibernate bi-directional
  • Many to Many Relation in Hibernate
  • HQL: The Hibernate Query Language
  • Criteria Queries
  • Criteria Queries : Equal (eq), Not Equal(ne), Less than (le), greater than (gt),greater than or equal(ge) and Ordering the results
  • Criteria Queries: And OR conditions
  • Hibernate generator to generate id (primary key)
  • prevent concurrent update in Hibernate,slate object updatation in Hibernate,version checking in Hibernate

    Struts


  • Model View Controller (MVC)
  • Model View Controller (MVC)
  • Struts Flow-How Struts Works?
  • Struts Tutorial - Struts Setup- First Struts Action class setup
  • Message Resources
  • Validation Framework
  • Validation Framework-client side
  • ForwardAction
  • IncludeAction
  • DispatchAction
  • LookupDispatchAction
  • DynaActionForm
  • DynaActionForm
  • Struts Tutorial - Mutli-click prevention using struts tokens-Prevent Duplicate Submission
  • Logic Iterate Map and List

    JSP


  • JSP Tutorial
  • Introduction to JSP
  • JSP Comments
  • JSP Syntax
  • JSP Scripting Elements :Scriptlet, expression, declaration
  • JSP Directives
  • implicit objects in JSP
  • JSP Actions
  • Introduction to JSP
  • jsp:useBean
  • The jsp:setProperty Action
  • The jsp:getProperty Action
  • Introduction to JSP

    Spring


  • Spring Tutorial
  • Introduction to Spring
  • Benefits of Using Spring Framework
  • Inversion of Control in Spring
  • Introduction to BeanFactory
  • Dependency Injection in Spring
  • Collections Setter Injection
  • Bean Scopes in Spring
  • Spring IOC Setup Step by Step
  • Bean Lifecycle in Spring
  • ApplicationContext
  • MessageSources in Spring
  • Web Spring MVC framework
  • Developing Your First Spring Web Application
  • Developing Your Second Spring Web Application with Spring Form
  • Developing Your First Spring Web Application with Spring Validation Framework with Code Example
  • Spring integration with Hibernate
  • From a list, identify the purpose, behavior, and responsibilities of the bean provider for a CMP entity bean, including but not limited to: setEntityContext, unsetEntityContext, ejbCreate, ejbPostCreate, ejbActivate, ejbPassivate, ejbRemove, ejbLoad, ejbStore, ejbFind, ejbHome, and ejbSelect.

    The entity Bean Provider is responsible for implementing the following methods in the abstract entity bean class:

    • A public constructor that takes NO arguments.

    • public void setEntityContext(EntityContext ic);

      A container uses this method to pass a reference to the EntityContext interface to the entity bean instance. If the entity bean instance needs to use the EntityContext interface during its lifetime, it must remember the EntityContext interface in an instance variable. This method executes with an UNSPECIFIED transaction context An identity of an entity object is NOT available during this method. The entity bean MUST NOT attempt to access its persistent state and relationships using the accessor methods during this method. The instance can take advantage of the setEntityContext() method to allocate any RESOURCES that are to be held by the instance for its lifetime. Such resources cannot be specific to an entity object identity because the instance might be reused during its lifetime to serve multiple entity object identities.

    • public void unsetEntityContext();

      A CONTAINER invokes this method before terminating the life of the instance. This method executes with an UNSPECIFIED transaction context. An identity of an entity object is NOT available during this method. The entity bean MUST NOT attempt to access its persistent state and relationships using the accessor methods during this method. The instance can take advantage of the unsetEntityContext() method to free any resources that are held by the instance. (These resources typically had been allocated by the setEntityContext() method.)

    • public [primary key class] ejbCreate<METHOD>(...);

      There are ZERO or more ejbCreate<METHOD>(...) methods, whose signatures match the signatures of the create<METHOD>(...) methods of the entity bean’s home interface. The CONTAINER invokes an ejbCreate<METHOD>(...) method on an entity bean instance when a CLIENT invokes a matching create<METHOD>(...) method on the entity bean’s home interface.

      The entity Bean Provider’s responsibility is to INITIALIZE the instance in the ejbCreate<METHOD>(...) methods from the input arguments, using the get and set accessor methods, such that when the ejbCreate<METHOD>(...) method returns, the persistent representation of the instance can be created. The entity Bean Provider is guaranteed that the values that will be initially returned by the instance’s get methods for container-managed fields will be the Java language defaults (e.g. 0 for integer, null for pointers), except for collection-valued cmr-fields, which will have the empty collection (or set) as their value. The entity Bean Provider MUST NOT attempt to modify the values of cmr-fields in an ejbCreate<METHOD>(...) method. This should be done in the ejbPostCreate<METHOD>(...) method instead.

      The entity object created by the ejbCreate<METHOD> method MUST have a unique primary key. This means that the primary key MUST be different from the primary keys of all the existing entity objects within the SAME HOME. However, it is LEGAL to reuse the primary key of a previously removed entity object. The implementation of the Bean Provider’s ejbCreate<METHOD>(...) methods should be coded to return a NULL. An ejbCreate<METHOD>(...) method executes in the transaction context determined by the transaction attribute of the matching create<METHOD>(...) method, as described in subsection. The database insert operations are performed by the container within the same transaction context after the Bean Provider’s ejbCreate<METHOD>(...) method completes.

    • public void ejbPostCreate<METHOD>(...);

      For each ejbCreate<METHOD>(...) method, there is a matching ejbPostCreate<METHOD>(...) method that has the same input parameters but whose return type is void. The container invokes the matching ejbPostCreate<METHOD>(...) method on an instance after it invokes the ejbCreate<METHOD>(...) method with the same arguments. The instance CAN discover the primary key by calling getPrimaryKey() on its entity context object.

      The entity object identity is AVAILABLE during the ejbPostCreate<METHOD>(...) method. The instance MAY, for example, obtain the component interface of the associated entity object and pass it to another enterprise bean as a method argument.

      The entity Bean Provider MAY use the ejbPostCreate<METHOD>(...) to set the values of cmr-fields to complete the initialization of the entity bean instance.

      An ejbPostCreate<METHOD>(...) method executes in the SAME transaction context as the previous ejbCreate<METHOD>(...) method.

    • public void ejbActivate();

      The container invokes this method on the instance when the container picks the instance from the pool and assigns it to a specific entity object identity. The ejbActivate() method gives the entity bean instance the chance to acquire additional resources that it needs while it is in the ready state.

      This method executes with an UNSPECIFIED transaction context. The entity bean MUST NOT attempt to access its persistent state or relationships using the accessor methods during this method.

      The instance CAN obtain the IDENTITY of the entity object via the getPrimaryKey(), getEJBLocalObject(), or getEJBObject() method on the entity context. The instance CAN rely on the fact that the primary key and entity object identity will remain associated with the instance until the completion of ejbPassivate() or ejbRemove().

    • public void ejbPassivate();

      The container invokes this method on an instance when the container decides to disassociate the instance from an entity object identity, and to put the instance back into the pool of available instances. The ejbPassivate() method gives the instance the chance to release any resources that should not be held while the instance is in the pool. (These resources typically had been allocated during the ejbActivate() method.)

      This method executes with an UNSPECIFIED transaction context. The entity bean MUST NOT attempt to access its persistent state or relationships using the accessor methods during this method.

      The instance CAN still obtain the IDENTITY of the entity object via the getPrimaryKey(), getEJBLocalObject(), or getEJBObject() method of the EntityContext interface.

    • public void ejbRemove();

      The container invokes the ejbRemove() method on an entity bean instance in response to a client-invoked remove operation on the entity bean’s home or component interface or as the result of a cascade-delete operation. The instance is in the ready state when ejbRemove() is invoked and it will be entered into the POOL when the method completes.

      The entity Bean Provider CAN use the ejbRemove method to implement any actions that must be done BEFORE the entity object’s persistent representation is removed.

      The CONTAINER synchronizes the instance’s state BEFORE it invokes the ejbRemove method. This means that the state of the instance at the beginning of the ejbRemove method is the same as it would be at the beginning of a business method.

      This method and the database delete operation(s) execute in the transaction context determined by the transaction attribute of the remove method that triggered the ejbRemove method. The instance CAN still obtain the IDENTITY of the entity object via the getPrimaryKey(), getEJBLocalObject(), or getEJBObject() method of the EntityContext interface.

      After the entity Bean Provider’s ejbRemove returns, and in the same transaction context, the Container removes the entity bean from all relationships in which it participates before removing the entity object’s persistent representation.

      Since the instance will be entered into the POOL, the state of the instance at the end of this method MUST be equivalent to the state of a passivated instance. This means that the instance must release any resource that it would normally release in the ejbPassivate() method.

    • public void ejbLoad();

      When the container needs to synchronize the state of an enterprise bean instance with the entity object’s persistent state, the container calls the ejbLoad() method.

      The entity Bean Provider CAN assume that the instance’s persistent state HAS BEEN LOADED just BEFORE the ejbLoad() method is invoked. It is the responsibility of the Bean Provider to use the ejbLoad() method to recompute or initialize the values of any instance variables that depend on the entity bean’s persistent state. In general, any transient state that depends on the persistent state of an entity bean should be recalculated using the ejbLoad() method. The entity bean can use the ejbLoad() method, for instance, to perform some computation on the values returned by the accessor methods (for example, uncompressing text fields).

      This method executes in the transaction context determined by the transaction attribute of the business method that triggered the ejbLoad method.

    • public void ejbStore();

      When the container needs to synchronize the state of the entity object’s persistent state with the state of the enterprise bean instance, the container first calls the ejbStore() method on the instance.

      The entity Bean Provider should use the ejbStore() method to UPDATE the instance using the accessor methods BEFORE its persistent state is synchronized. For example, the ejbStore() method may perform compression of text before the text is stored in the database. The Bean Provider CAN assume that AFTER the ejbStore() method returns, the persistent state of the instance is synchronized.

      This method executes in the SAME transaction context as the previous ejbLoad or ejbCreate method invoked on the instance. All business methods invoked between the previous ejbLoad or ejbCreate<METHOD> method and this ejbStore method are also invoked in the SAME transaction context.

    • public [primary key type] or [collection] ejbFind<METHOD>(...);

      The Bean Provider of an entity bean with container-managed persistence DOES NOT write the finder (ejbFind<METHOD>(...)) methods.

      The finder methods are generated at the entity bean DEPLOYMENT time using the Container Provider’s tools.

      Every finder method except findByPrimaryKey(key) MUST be associated with a query element in the deployment descriptor. The entity Bean Provider declaratively specifies the EJB QL finder query and associates it with the finder method in the deployment descriptor. A finder method is normally characterized by an EJB QL query string specified in the query element.

      
      <entity>
      	...
      	<query>
      		<query-method>
      			<method-name>findAllCustomersWithReservations</method-name>
      			<method-params/>
      		</query-method>
      		<ejb-ql>
      			SELECT OBJECT(cust) 
      			FROM Reservation res, IN (res.customers) cust
      		</ejb-ql>
      	</query>
      	...
      </entity>	
      
      								

    • public [some type] ejbHome<METHOD>(...);

      The container invokes this method on the instance when the container selects the instance to execute a matching client-invoked <METHOD>(...) home method. The instance is in the POOLED state (i.e., it is not assigned to any particular entity object identity) when the container selects the instance to execute the ejbHome<METHOD> method on it, and it is returned to the POOLED state when the execution of the ejbHome<METHOD> method completes.

      The ejbHome<METHOD> method executes in the transaction context determined by the transaction attribute of the matching <METHOD>(...) home method.

      The entity bean provider provides the implementation of the ejbHome<METHOD> method. The entity bean MUST NOT attempt to access its persistent state or relationships using the accessor methods during this method because a home method is NOT SPECIFIC to a particular bean instance.

    • public abstract [some type] ejbSelect<METHOD>(...);

      The Bean Provider may provide ZERO or more SELECT METHODS. A select method is a query method that is NOT DIRECTLY EXPOSED to the client in the home or component interface. The Bean Provider typically calls a select method within a business method.

      The Bean Provider defines the select methods as abstract methods.

      The select methods are generated at the entity bean deployment time using the Container Provider’s tools.

      The ejbSelect<METHOD> method executes in the transaction context determined by the transaction attribute of the invoking business method.

      The semantics of a select method, like those of a finder method, are defined by an EJB QL query string. A select method is similar to a finder method, but unlike a finder method it can return values that correspond to ANY cmp-field or cmr-field type.

      Every select method MUST be associated with a query element in the deployment descriptor. The entity Bean Provider declaratively specifies the EJB QL query and associates it with the select method in the deployment descriptor. A select method is normally characterized by an EJB QL query string specified in the query element.

      								
      <entity>
      	...
      	<query>
      		<query-method>
      			<method-name>ejbSelectZipCodes</method-name>
      			<method-params>
      				<method-param>java.lang.String</method-param>
      			</method-params>
      		</query-method>
      		<ejb-ql>
      			SELECT a.zip FROM Address AS a
      			WHERE a.state = ?1
      		</ejb-ql>
      	</query>
      	...
      </entity>	
      
      								

      Typically an ejbSelect<METHOD>(...) method that returns entity objects returns these as EJBLocalObjects. If the ejbSelect<METHOD>(...) method returns an EJBObject or collection of EJBObjects, the Bean Provider MUST specify the value of the result-type-mapping element in the query deployment descriptor element for the select method as Remote.

      An ejbSelect<METHOD>(...) is NOT based on the IDENTITY of the entity bean instance on which it is invoked. However, the Bean Provider CAN use the primary key of an entity bean as an argument to an ejbSelect<METHOD>(...) to define a query that is logically scoped to a particular entity bean instance.

    The information you are posting should be related to java and ORACLE technology. Not political.