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
  • Interface and methods of Session Bean

    A container provides the session bean instances with a SessionContext, which gives the session bean instance access to the instance’s context maintained by the container. The SessionContext interface has the following methods:

    • The getEJBObject method returns the session bean’s remote interface.

    • The getEJBHome method returns the session bean’s remote home interface.

    • The getEJBLocalObject method returns the session bean’s local interface.

    • The getEJBLocalHome method returns the session bean’s local home interface.

    • The getCallerPrincipal method returns the java.security.Principal that identifies the invoker of the bean instance’s EJB object.

    • The isCallerInRole method tests if the session bean instance’s caller has a particular role.

    • The setRollbackOnly method allows the instance to mark the current transaction such that the only outcome of the transaction is a rollback. ONLY instances of a session bean with CONTAINER-managed transaction (CMT) demarcation can use this method.

    • The getRollbackOnly method allows the instance to test if the current transaction has been marked for rollback. ONLY instances of a session bean with CONTAINER-managed transaction (CMT) demarcation can use this method.

    • The getUserTransaction method returns the javax.transaction.UserTransaction interface. The instance can use this interface to demarcate transactions and to obtain transaction status. ONLY instances of a session bean with BEAN-managed transaction demarcation (BMT) can use this method.

    public interface SessionContext extends EJBContext {
    	EJBLocalObject getEJBLocalObject() throws IllegalStateException;
    	EJBObject getEJBObject() throws IllegalStateException;	
    }					
    
    public interface EJBContext {
    	EJBHome getEJBHome();
    	EJBLocalHome getEJBLocalHome();
    	java.security.Principal getCallerPrincipal();
    	boolean isCallerInRole(String roleName);
    	UserTransaction getUserTransaction() throws IllegalStateException;
    	void setRollbackOnly() throws IllegalStateException;
    	boolean getRollbackOnly() throws IllegalStateException;
    }
    
    /**
     * This interface represents the abstract notion of a principal, which
     * can be used to represent any entity, such as an individual, a
     * corporation, and a login id.
     */
    public interface Principal {
        public String getName();
    }
    					

    The ejbRemove notification signals that the instance is in the process of being removed by the container. In the ejbRemove method, the instance typically releases the same resources that it releases in the ejbPassivate method.

    The Bean Provider CANNOT assume that the Container will always invoke the ejbRemove() method on a session bean instance. The following scenarios result in ejbRemove() NOT being called on an instance:

    • A crash of the EJB Container.

    • A SYSTEM exception thrown from the instance’s method to the Container.

    • A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB Container implementation specific way.

    If the session bean instance allocates resources in the ejbCreate<METHOD>(...) method and/or in the business methods, and normally releases the resources in the ejbRemove() method, these resources will not be automatically released in the above scenarios. The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources.

    The ejbPassivate notification signals the intent of the container to passivate the instance. The ejbActivate notification signals the instance it has just been reactivated. Because containers automatically maintain the conversational state of a session bean instance when it is passivated, most session beans can ignore these notifications. Their purpose is to allow session beans to maintain those open resources that need to be closed prior to an instance’s passivation and then reopened during an instance’s activation (for example, DB connections).

    A STATEFUL session bean class (CMT only) can optionally implement the javax.ejb.SessionSynchronization interface. This interface provides the session bean instances with transaction synchronization notifications. The instances can use these notifications, for example, to manage database data they may cache within transactions :

    • The afterBegin notification signals a session bean instance that a new transaction has begun. The container invokes this method before the first business method within a transaction (which is not necessarily at the beginning of the transaction). The afterBegin notification is invoked with the transaction context. The instance may do any database work it requires within the scope of the transaction.

    • The beforeCompletion notification is issued when a session bean instance’s client has completed work on its current transaction but prior to committing the resource managers used by the instance. At this time, the instance should write out any database updates it has cached. The instance can cause the transaction to roll back by invoking the setRollbackOnly method on its session context.

    • The afterCompletion notification signals that the current transaction has completed. A completion status of true indicates that the transaction has committed; a status of false indicates that a rollback has occurred. Since a session bean instance’s conversational state is not transactional, it may need to manually reset its state if a rollback occurred.

    public interface SessionSynchronization {
    	void afterBegin() throws EJBException, RemoteException;
    	void afterCompletion(boolean committed) throws EJBException, RemoteException;
    	void beforeCompletion() throws EJBException, RemoteException;
    }
    					
    ONLY a STATEFUL Session bean with CONTAINER-managed transaction (CMT) demarcation may implement the SessionSynchronization interface. A stateless Session bean MUST NOT implement the SessionSynchronization interface.

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