Bill Robertson

Eugene, i totally got yeah. thanks

Eugene,
Could you elaborate on what you mean by the following:
Create 50 client threads, each incrementing a field of the same database record, 10000 times in a row, for each thread. If at the end of the test run the field is icremented by exactly 500000, in all likelihood you will pass the certification.
I understand the 50 client thing and how to set up the threads and all that, but what do you mean by each incrementing a field? What field is incremented. Do you just mean changing the value of something like a booking field 1000 times. Its your use of increment that I don't understand.
thanks,
bill

Have you tried something like:
import java.net.InetAddress;
int ID = InetAddress.getLocalHost().hashCode();

double that

Andrew, sometimes you scare me.

Hey Javini,
Think about what SUN is saying "Use of functionality provided by
the core java classes will be prefered to your own implementation."
The key word here is core java classes which is a reference to the
API's. So in other words dont try to reinvent the wheel. (ex. Creating
you own ArrayList class)
Is javax.swing.SwingUtilities.SwingWorker and Swing Spring class part of
the core API's? NO!!! They are example's owned by sun and I believe
if you read in the copyright of each of these classes it states that you cannot use the code. However, if you understand how they work, there is
nothing wrong with coming up with your own implementation even if it looks
similar to the SUN examples. But just dont cut and paste!!!
[ January 07, 2004: Message edited by: Bill Robertson ]
[ January 07, 2004: Message edited by: Bill Robertson ]

RW is suffice.

excellent advice George!

yeah, thats how I have it exactly

I am going over some nit picky details and one thing I forgot about is
whether or not a user should be allowed to book a contractor after it has
already been booked by another user. This seems pointless and totally
goes against system integrity but I know Ken did it this way and he scored
very high. I was wondering what others thought.
Example:
contractor x is booked by owner id 345 by client John. Client Mike comes
a long books contractor x with owner id 670 and no notification or anything
is sent to notify John. Client Mike just totally wipes out what John booked
and I would think John expects to see his booking the next time he longs on.
So basically I am leaning towards not letting them book a contractor once it is booked. Instead I will document they should have a managerial process in place to make a change. What does everyone else think?

Hey Javini,
IMO, what you have is a rather confusing design. Why ?
1. First off, exceptions are part of the signature of a method. So if more exceptions come along, yes your method may brake without "throws Exception",
but that could be a good thing because you get notified of the changes automatically. Changes that you may not agree with or may have a negative
impact on what your trying to accomplish.
2. Also the signature of a method is like a contract. It some what gives away what the method can do and what it's used for. If you just have "throws Exception" you are not telling other users very much about what the method really does.
3. And most importantly, how are those calling your method going to handle
the exceptions properly? Do you expect them to trace through the methods code to determine the exact exceptions it throws so they can catch them and
respond properly. You do not want this, which is why we put the exceptions that a method throws in its signature in the first place.
just my simple two cents worth

They do this just to confuse you. JRMP, or Java Remote Method Protocol, is the default protocol created by SUN for RMI. In fact you will not even hear SUN refer to JRMP as JRMP. Instead they say the "RMI transport protocol". So basically you do not have to do anything!!!
Use RMI and it will default to JRMP. It is a low level, wire level actually, protocol. By the way there is a JRMP API (net.jini.jrmp).

Hey Ken,

In my case, unlock only looks in the locked map, not the contractors collection, so it only throws RecordNotFoundException if it's not in the locked map.

makes sense and clears things up for me - thanks

In my case, if the lock method looks in the contractor collection and can't find it, the exception will be thrown and update will never be called. Once it finds it during lock, it should not fail during the update invocation because the lock prevents any other thread from deleting it. My book method contains the calls to lock/update/unlock and throws RecordNotFoundEception up to its client if it occurs and the client will report it to the user.

I see, so your contract for update also applys to book - am I correct?
This is a very nice solution. My only minor issue is calliing RecordNotFoundException for two different conditions. Unlock if not in
locked collection, for lock if not in contractor collection. But its the nicest solution I have seen yet.
thanks Ken,
bill

2 Qustions that have been bothering me since day one:
1. For delete how do you handle unlock. In a sense you can't. But lets
say you log on and delete record 4, then immediatly create a new record
that ends up in the 4th space - so its now the fourth record. But in your
Collection that you store your locked objects, record 4 is going to be in
there as locked - which makes no sense! - it was just created.
2. Very similar to number 1, how do you handle
RecordNotFoundException thrown from lets say book. You can either not call
unlock which then you run into problem number 1, or your unlock ends up
throwing it also so you loose the actual trace and integrity of where the
exception first occured.
I split up my unlock so that the actual unlocking of the record takes
place in another method that unlock calls. Its only parameter is record
number. Would just calling this method and not the entire unlock method be
a valid solution?
[ January 01, 2004: Message edited by: Bill Robertson ]

hi george,
i see your point, but i do not see how this would prevent placing a new record into a position that is locked in my lock collection. because remember whenever you enter create you have no idea where yor new record is going to go.
bill