Help coderanch get a
new server
by contributing to the fundraiser

Dave Landers

Ranch Hand
+ Follow
since Jul 24, 2002
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Landers

Each request is processed by a thread. This just means that many requests can be processed at the same time.
Also, the servlet spec says that the servlet container can use any instance of the servlet object for these multiple threads. That lets the servlet engine be more efficient (fast).
The result for servlet developers is that we can not put read/write shared data in fields of the servlet object. The object can be reused by multiple threads at the same time, so this data will be "stomped on" by other threads. All data must be maintained as method-local variables.
So when you are writing your servlet, it all starts with the service method (or doGet or doPost or whatever). If you call other methods from there, you need to pass all the data around as method arguments and do not save it in the servlet object.
In this regard, the request and response objects are no different than any other value - don't save them as fields of the servlet object.
There are several ways in which you can save data for a single user or request - you can use the HttpSession to save user data between requests or you can use the Attributes on the request to save data for the duration of a single request.
The servlet API does have a SingleThreadedModel interface. If your servlet implements this interface, it instructs the servlet container not to share instances between threads. You can use this if you absolutely must put fields on your servlet object. But it is better not to do that as this really limits the performance of your server.
21 years ago
You did not create two instances, only one.
You have two variables which reference the same singleton instance.
You can test that by checking that instance==instance1.
The reason they both have the same contents is because they are the same object.
21 years ago
I think what may be happening is that WebLogic is not Serializing the collection. WLS will serialize things if it can't see the same class from both ClassLoaders.
Maybe because the Collection is in java.util it is not actually serializing that object, so its contents (your Value objects) are not being serialized and thus you get the ClassCastException.
I can think of three ideas. You can force the serialization with a switch in the weblogic-ejb-jar.xml (I forget exactly, but check
Or you could put your value class in system classpath.
Or you could create a subclass of the Collection that you put in your ejb jar and client jar in the webapp. Pass the "MyCollection" rather than the java.util.Collection and maybe WLS will be "tricked" into serializing the thing. It could be as simple as

I think the force serialization switch is probably the best bet.
[ November 22, 2002: Message edited by: Dave Landers ]
OK, to clarify what I meant.
In order for an object to be constructed (and thus have some combination of constructors invoked) somebody has to make a call to new.
While that is going on, other threads can not get a reference to that object until it is constructed (exception -see below). And in any case when another gets the instance, it can not invoke the constructor. A second threads can not invoke any constructor on the same object instance.
Therefore the constructors themselves are "thread-safe", and the only concern is the thread safety of objects that are used by those constructors.
Exception: What I said above about "other threads can not get a reference till it is constructed" is not strictly true. It is true enough for the explaination above, but it still has a hole. The reason is all wrapped up in the Java Memory Model. Its the same reason that Double Checked Locking doesn't work in Java. Don't need to go into that into too much detail here.
The manifest format is very picky. Use

That's a colon ( not an equals (=).
Also, I think the space after the colon is important.
Make sure, if this is the only thing in your MANIFEST.MF, that it also ends in a newline.
And this goes in the manifest of the EJB jar, not anywhere else.
[ November 22, 2002: Message edited by: Dave Landers ]
21 years ago
Note that some code somewhere has to call something like:
new TheObject()
for the constructor to be run.
Since a constructor is only run while the object is being created, thread safety of the constructor itself is not an issue. This is because two threads can't create the same object. If they are creating objects, they will create different ones.
Thus it does not make sense to have a synchronized keyword for a constructor.
Now what the constructor is doing is another matter. If it is accessing some common resource (another object or static methods/fields) then there could be a problem. But this is no different than any method's access of those resources. Those resources should be protected in either case.
You probably need tools.jar in your classpath. You should find it in your JDK's lib directory.
The state for a stateful session bean is maintained as fields in the object.

If the container has to passivate the bean (maybe it has to make "room" for other more active beans), it might serialize the thing to a file on disk. Before the client uses it again, it will be deserialized and the bean activated. But all you care (as the developer) is that you wrote an object and the data is referenced by fields.
But think about why you are using stateful session beans. They can be misused and put a burden on the server.
Just because it has "session" in its name does not mean it is anything at all like the http session object. It is not a replacement.
I usually prefer to keep the ejb's api stateless, and let the client keep the state. If the client is a webapp, this means the client's state is in http session. If the client is a java program, it means keeping the state in that program's memory.
I understand what you're saying.
First, I must say that anyone who can sleep thru 11 days of training deserves some kind of award (or the instructor does).
Although I have sat thru portions of some older versions (3.x, 4.5.1) of these courses and they weren't very exciting - but I had practical experience at the time and so the material was nothing new. I also beta-tested the first (4.5.1) cert test. Got a polyester shirt -
Seems to me the training option is not a bad one, especially for folks that can swing it. But maybe it would make sense to require a passing grade on a quiz to get the cert. They still have the same cert exams, and some kind of test-out of the course work, I think. So just more options.
Maybe it does change the value of the cert, but I'm not convinced.
Anyway, it doesn't really matter to me. I am not big on certs. I know lots of folks on JavaRanch are. Maybe I just thought I'd push a couple of JavaRanch Pro-Certification buttons
To me, the important thing is what you know and what you can do, not what papers you have pinned to your cubical wall.
If you have the opportunity to gain knowledge thru training (or thru any opportunity), then grab it. If you can get a piece of paper and a shirt outta the deal then great.
But know that neither the course work nor the test will really tell anyone if you can apply the knowledge that the paper claims you "learned".
21 years ago
an array is an Object.
Prove it to yourself:
21 years ago
In weblogic-ejb-jar.xml in the weblogic-enterprise-bean section, set:

Default is 30 seconds.
21 years ago
So a minimum of 11 days of training at a cost of over $6000 is "watered down" when compared to a 2 hour multiple choice test?
21 years ago
Did you try JDK 1.4? The character encoding stuff is much improved in 1.4.
21 years ago
pointbase driver should be in the pointbase eval directory. I forget exactly where it was in 6.1, but something like weblogic/samples/eval/pointbase/lib/pbserverXX.jar
21 years ago