Marc

Greenhorn
+ Follow
since Mar 10, 2000
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 Marc

Originally posted by Douglas Kent:
What happens to the RMI-based scheme in local mode?


Douglas,
you do not need locking for local mode access since you do not have any concurrency...
Surely the case where 'several users simultaneously access a local database from different JVMs on the same machine' is not worth considering !?
Regards,
Marc
Top stuff Aaron. Thanks for the report - very helpful indeed.
Marc
Hi Vijay,
A stateless session bean could have e.g. a credit card verification functionality - you hand in details, the bean checks whether your purchase can go through, returns a boolean and exits. Here a session is made up of a single invocation: the bean's service represents an atomic action. As soon as a session involves more than a single request, you need to save state.
A bean becomes an entity bean by implementing javax.ejb.EntityBean. Similarly, session beans implement javax.ejb.SessionBean. Also, make sure the fields in the deployment descriptor match the implementation of your beans.
For a stateful session bean, the developers have to keep track of the state themselves (by creating appropriate fields within the bean..e.g. Vector shoppingList for my earlier example). They also have to implement the ejbActivate() and ejbPassivate() methods since EJB containers may choose to passivate any beans as part of resource management..However, the single point which "decides" whether a session bean is stateful or stateless, as far as I can see, is the *session-type* field in the deployment descriptor.
Regards,
Marc
[This message has been edited by Marc (edited June 07, 2000).]
Hi Vijay,
an entity bean models a data item that you want to persist in a lasting way. This means that any changes to its data fields will be written to an underlying RDBMS either transparently (CMP) or using your own implementations of
store()/create() etc. methods if you're after a custom mapping.
For instance, an entity EJB within a banking system might be used to represent one customer, along with their details. You don't want to lose those details when the customer disconnects!
That persistence interval aspect is what makes entity beans different from stateful session beans. A shopping cart EJB will total up customer choices while that customer is on your shopping website. It needs to monitor session or "conversational" state for that well-defined interval which is 'one customer visit to my website'. However, unless you're after statistics for data mining (which is another question), you don't care for that data after the customer has left. Hence there is no need to persist it to a database: any session data gets discarded (or may get discarded) after the session ends.
Hope this helps,
Marc
Hi Shafeeq,
it is true that the most significant bit is set to 1 for negative numbers, but you don't simply copy the other bits.
Basically what you use is the representation called 2's complement. It involves setting the MSB to 1, inverting the remaining bits (giving you 1's complement), then adding 1 .
The MSB is then subtracted and the remaining digits added, always giving a negative result since the MSB equals the sum of all other digits plus 1.
Thus -8=1000 (-8+0+0+0)
-7=1001 (-8+0+0+1)
-1=1111 (-8+4+2+1)
....
Finding this through taking the 2's complement:
To find -7 form 7: 0111
Invert to 1's complement: 1000
Add 1 for 2's complement: 1001
This means that, if you use 8 bits, you can only express numbers from -128 (10000000) to +127 (01111111); +128 is not possible since you can only use 7 bits for the positive value.
Hope this helps..
Marc
21 years ago
Hi Ray,
not sure why you're getting
*Can't convert int to java.lang.Float*. If I cut and paste your code, I get
*Can�t convert float to java.lang.Float*
which makes sense:
field1.getText() -> gives String
Float.valueOf(field1.getText()) -> gives Float
(Float.valueOf ( field1.getText ( ))).floatValue ( )
-> gives float (note lowercase)
Thus you are trying to assign a var of primitive type float to an Object reference of type Float, which doesn't work.
Obviously you want float so you can perform the addition, so what would work is the following:
//can add two floats
float result = (Float.valueOf ( field1.getText ( ))).floatValue ( ) + (Float.valueOf ( field2.getText ( ))).floatValue ( ) ;
//can call valueOf on float since valueOf() exists both for
//primitive types and Object - look it up
label1.setText ( String.valueOf ( result)) ;
And there you go.
You should also change the duplicate initialisation of field1 since addition results might otherwise be unexpected :-)
And have a look at the static Float.parseFloat() method which can be used to achieve the same thing in a less convoluted way.
Hope this helps,
Marc

[This message has been edited by Marc (edited May 12, 2000).]
21 years ago
Hi Jon,
what you need to type is
j2ee [-verbose]
NOT java -verbose j2ee (or whatever).
Hope this helps,
Marc
Hi Divakar,
c1.start();
c2.start();
System.out.println("main");
calls to start threads are asynchronous. In this instance, this means the main() thread registers a call with the JVM to start c1 i.e. set up the c1 thread and call its run() method, immediately goes on to do the same for c2 without waiting until c1 has actually started, then immediately continues execution, i.e. prints "main", without waiting for c2 to start.
Meanwhile, the JVM allocates memory etc. for c1 and c2 when it can find the time and resources. You cannot even guarantee whether c1 will initialise before c2; it all depends on resource management. Getting the threads running will always take much longer than it takes the main() thread to rush through the println statement; hence you are getting that output first.
Hope this helps
Marc

Originally posted by Jim Yingst:
Regarding answer C - there's actually no guarantee that a higher-priority thread will pre-empt a lower-priority thread, so it's not unreasonable to use yield() in a lower-priority thread if you want to make things even easier for the higher-priority thread. So I'd agree with Umesh on this one, C should be a valid answer.


Hi,
excellent points there . I cannot stand questions on garbage collection and Threads and this is why - most definite statements go out the window as soon as you accept the subsystem is platform dependent!
I tend to think of Threads as existing twice - once as a high-level blue-sky Java abstraction governed by application-layer thread priority, and once as machine-dependent kernel things.
The machine dependence is well out of reach of the Java programmer so in that sense your case for C sounds like the correct one - use what you have got to make it as LIKELY as possible that the thread will be schedule the way you hope.
My own (limited) experience says that thread priority does play a very strong role in thread scheduling, with the higher priority thread getting plenty of execution time regardless of lower-priority ones calling yield or not. But then again, I have only used one type of hardware platform so this experience may, of course, reflect the underlying Solaris scheduler!
I guess the bit that should determine the answer is what Sun thinks the answer should be..and my belief is that they would rather not have answer C since the need for such an action would slightly ridicule Java thread scheduling. What is the point of Thread priority if higher-order threads (notice the question does not state the high-priority thread is in a waiting condition of any kind!) have to rely on lower-priority ones to yield, thus "allowing"(!) them to run?
So I still think my exam answer to this would be A only. But then, I have not taken the exam yet, and am very unlikely to get anywhere near 97%...
Regards,
Marc

Originally posted by Jim Yingst:
Regarding answer C - there's actually no guarantee that a higher-priority thread will pre-empt a lower-priority thread, so it's not unreasonable to use yield() in a lower-priority thread if you want to make things even easier for the higher-priority thread. So I'd agree with Umesh on this one, C should be a valid answer.


Hi,
excellent points. I cannot stand questions on garbage collection and Threads and this is why - most definite statements go out the
window as soon as you accept the subsystem is platform dependent!
I tend to think of Threads as existing twice - once as a high-level blue-sky Java abstraction governed by application-layer thread priority, and once as machine-dependent kernel things.
The machine dependence is well out of reach of the Java programmer so in that sense your case for C sounds like the correct one - use what you have got to make it as LIKELY as possible that the thread will be schedule the way you hope.
My own (limited) experience says that thread priority does play a very strong role in thread scheduling, with the higher priority thread getting plenty of execution time regardless of lower-priority ones calling yield or not. But then again, I have only used one type of hardware platform so this experience may, of course, reflect the underlying Solaris scheduler!
I guess the bit that should determine the answer is what Sun thinks the answer should be..and my belief is that they would rather not have answer C since the need for such an action would slightly ridicule Java thread scheduling. What is the point of Thread priority if higher-order threads (notice the question does not state the high-priority thread is in a waiting condition of any kind!) have to rely on lower-priority ones to yield, thus "allowing"(!) them to run?
So I still think my exam answer to this would be A only. But then, I have not taken the exam yet, and am very unlikely to get anywhere near 97%...
Regards,
Marc

Originally posted by Umesh:
Under what circumstances might you use the
yield method of the Thread class
A. To call from the currently running thread to allow
another thread of the same priority to run ....ans
B. To call on a waiting thread to allow it to run ....why not
C. To allow a thread of higher priority to run ....why not
D. To call from the currently running thread with a
parameter designating which thread should be allowed
to run.


Umesh,
B. Because yield() takes away control from the currently running
thread instead of giving it to the one called on.
C. Because higher-priority threads are going to run anyway..that is what thread priorities are for.
Regards
Marc