Only 44 hours left in the trailboss' kickstarter!

New rewards and stretch goals. CLICK HERE!



  • Post Reply Bookmark Topic Watch Topic
  • New Topic

ejbFindByPrimaryKey()  RSS feed

 
Vishal Saxena
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
At least one such method needs to be implemented in case of BMP; if it's CMP the container does so in the generated child class.
The argument to it is the primary key.
The return arg to it is the primary key. The container then associates an EJBObject with it and passes it to the client.
In effect, what this method is accomplishing is just checking whether data corresponding to the primary key exists; if not throws a FinderException. Is it not ? You give a pk, you get a pk.
Am I thinking right ?
- An EJB Novice.
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If it does not throw a FinderException, you will get an entity bean instance representing the record pointed by the pk. In essence, you give a pk and you get back the record.
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey ajith,
Since the bean instances are pooled and one of the bean instances is used for serving the find method, will the same bean instance be eventually serving the client thru the ejbobject?
 
Maximilian Trenks
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
findByPrimaryKey() returns the remote interface of the found bean or returns an exception.
You can call your business methods on the entity bean via the remote interface.
however, keep in mind each getXXXXX() method represents a remote call (if no local interfaces are used). look for the session fascade pattern to reduce remote calls. hope that helps a bit.
 
william kane
Ranch Hand
Posts: 260
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Maximilian Trenks:
[QB]findByPrimaryKey() returns the remote interface of the found bean or returns an exception.
QB]

This is exactly my question.What does finding the bean mean?As far as my understanding goes one of the beans in the pool is picked up to serve the findXXX method in the home interface.The implementation of the findXXX method will lookup the database and return the PK only if a record for the PK is found.What happens after this and before i get an EJBobject?How is a bean instance assigned to the EJBObject?
 
Nitzan Levi
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,
you have to seperate the bean as a java class from the bean as a data entity. when you activate the find method you are using the bean class(witch can be one of the 10 or 15 generated classes that the dev tool is creating) to check if the data exists in the DB according to the PK.
the PK returnd from the find method is not for the user it's for the container that then creates an entity bean(EjbObject) that contains the data represented by the PK and thats what the user gets. now the user can work with the entity beans data .
hope it answers you'r question!
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by william kane:

Since the bean instances are pooled and one of the bean instances is used for serving the find method, will the same bean instance be eventually serving the client thru the ejbobject?

This is not a requirement. The EJB specifications does not cover this ground. It simply says entity bean "homes" should support finder methods and return a remote instance( or a collection of remotes in case of a multi-entity finder ) representing the underlying data. Whether or not the instance used to find becomes the instance returned to the caller is upto the implementation.
If you think about it, this approach fits very well into the concept of EJB instance pooling - as an EJB client, you only make calls to the home or remote interface. You should not worry and/or make any assumptions about the actual "bean instance" that serves the request. This will enable vendors to implement their own version of instance pooling algorithms while not deviating from the requirements of EJB specs.
[ April 24, 2003: Message edited by: Ajith Kallambella ]
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by william kane:

This is exactly my question.What does finding the bean mean?As far as my understanding goes one of the beans in the pool is picked up to serve the findXXX method in the home interface.The implementation of the findXXX method will lookup the database and return the PK only if a record for the PK is found.What happens after this and before i get an EJBobject?How is a bean instance assigned to the EJBObject?

Most vendors implement finders as follows -
If the finder returns a single object and it�s found, the container returns the found bean(see steps below). If the finder returns multiple object and some are found, an EJBObject and skeleton are created and the stub returned to the client. If the client decides to use the bean it will be activated on method request; if they don�t use the bean, the container has saved making a potentially expensive ejbLoad () call for each bean found.
Once the underlying record is located, the container performs the following operations
  • Checks out a bean from the pool and marks it as in-use.
  • Associates the bean with the EJBObject and sets the primary key. Consequently, the EJBObject or primary key can only safely be retrieved from the EntityContext as of the start of ejbPostCreate ()
  • Invokes ejbActivate() callback indicating that the bean is moving out of the pooled state.
  • Invokes ejbLoad() callback to load the underlying data.


  • Hope that helps.
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!