Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

Rajesh Shiggaon

Greenhorn
+ Follow
since Apr 25, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rajesh Shiggaon

Ideally, a remote client should be able to use an object reference across
a server crash and restart. An object reference should become invalid only when the entity object has been removed, or after a reconfiguration of the server environment (for example, when the entity bean is moved to a different EJB server or container).

The motivation for this is to simplify the programming model for the entity bean client. While the client code needs to have a recovery handler for the system exceptions thrown from the individual method invocations on the home and remote interface, the client should not be forced to re-obtain the object references.



I was just wondering, when a server gets crashed
1) skeleton on the server gets destroyed.
2) EJBObject gets destoryed.
3) EntityContext object also gets destroyed withe JVM crash (Which contains UserTransaction, holds the information abt the user), the primary key object etc.
So when it comes up how all these objects gets constructed? how come the client still is able to communicate with the entity bean?

Thanks
Rajesh S.
Guys:

While I was going through the EJB specification I found this statement, which made me some what confused
"While a crash of the Java Virtual Machine may result in a rollback of current transactions, it does not destroy previously created entity objects nor invalidate the references to the home and component interfaces held by clients"

If the client has a reference to the EJBObject, the JVM of the application server crashes and comes up after some time. Once it has come up, the client calls a business method through the EJBObject. How the container takes care of this. How is this possible?
Hi:

Please find my comments followed by rajesh

Here are the answers to ur q:

1) The primary key object thats gets generated after the create/finder methods from the EJBHome interface, how is that related with EJBObject?

In entity beans, findByPrimaryKey() returns a single ejb instance, representing a single row in the database table. The container wraps up this primary key to form an EJBObject, which is RMI compliant. This EJBObject provides an interface for clients to call business methods.

rajesh -- OK, for the first client i agree. Now another client fetches the same record, will the same EJBObject instance is return or a new one generated?

a) How the container relates this Primary object with EJBObject? I know that Container keeps track of this primary object.

- Refer above.

b) Lets say an Entity bean EJBObject has been created for a particular record. If a new client wants to access the same record a weather a new EJBObject gets created or the same one will be used? Will there be different Primary object instance also or only one?

- There are no EJBObjects created. There is only a pool of EJB instances in memory. When you write EJBs, u write a primary-key class. This class implements the equals() and hashcode(). The hashcode() is used by the container to check if two instances in memory have the same data. At any point of time, there is only one instance, representing a primary key.

rajesh -- EJBObjects are created (as you mentioned above), based on which the client can make a business call on the bean instance.
I am not sure weather there is only one instance of primary key or not, but as explained in the Mastering of EJB, the container can maintain multiple instance of entity bean representing the same data and uses the transaction attributes for ACID properties.

2) If you could see the "Client View of Entity Object Life Cycle" in the EJB spceification, they say that whenever we directly delete a record from a DB, how does the EJBObject also gets deleted with it?

- You dont directly delete a record. U delete the record by calling ejbRemove(). This deletes a row from the database. Also, it returns the ejb instance back to the pool.

rajesh -- i do understand we have to use the ejbRemove to remove the record in the DB, but lets suppose if we have another application which also uses the same DB, then that application can delete the record. So my question was put in that context

a) Does the container always keep on querying on the DB and then delete the EJBObject?


b) If it does not what is the use of the callback method of ejbLoad(). If it could not find the record based on the primary key that it gets, then how it should handle? it cant even written back an expection saying that the record doesnt exist

The ejbLoad() is used by the container to load the data from the db into a bean instance, based on the primary key value supplied. if it doesnt find the record, then it throws an exception.

rajesh -- if it throws an exception will that exception be written as RMIException? not sure on this part. As far the spec diagram tells us that the EJBObject does not exist once the record is directly deleted, there is no way it can call any methods on the entity bean instance.
Hi Everyone:

I have some questions on the entity beans, these have been bugging me for a quite time. So just thought of getting them straight.

1) The primary key object thats gets generated after the create/finder methods from the EJBHome interface, how is that related with EJBObject?
a) How the container relates this Primary object with EJBObject? I know that Container keeps track of this primary object.
b) Lets say an Entity bean EJBObject has been created for a particular record. If a new client wants to access the same record a weather a new EJBObject gets created or the same one will be used? Will there be different Primary object instance also or only one?

2) If you could see the "Client View of Entity Object Life Cycle" in the EJB spceification, they say that whenever we directly delete a record from a DB, how does the EJBObject also gets deleted with it?
a) Does the container always keep on querying on the DB and then delete the EJBObject?
b) If it does not what is the use of the callback method of ejbLoad(). If it could not find the record based on the primary key that it gets, then how it should handle? it cant even written back an expection saying that the record doesnt exist

If any of the questions are misleading or not understandable, let me know I can reframe those.

Thanks in advance

Rajesh Shiggaon
Hey Harshil:

Thanks for your response.

Why i want to public abstract void finalize() in class B, so that i can force all the subclasses to enforce of providing there own implementation of finalize method. If we try to do this i will not be able to call finalize method in class A. Then why to allow such kind of code? Does it make sense?

Do you have any other way that you can force that all subclasses should write the finalize method? Still we can do it use hook and cook. But it will not be elegant way of programming.

Thanks,
Rajesh S
Since the calling of finalize() in the Class A is not possible (I knew it), why the complier cant prevent this kind of code.

Thanks
Rajesh S
Hi Everyone:

I know we cannot use a super keyword for an abstract implemented method. But below is my class hirearchy. As you know finalize has to be explictily chained, how can i achieve this with my below code?

class A {
public void finalize(){
System.out.println("Inside the finaliaze method");
}

}

abstract class B extends A {
public abstract void finalize();
}

class C extends B {

public void finalize(){
System.out.println("Inside the class B");
//super.finalize(); How can I call the finalize method in Class A
}
}

Thanks in advance.

Rajesh Shiggaon