Habibi book contact info?

[Morgan Bath]

I have the book by Mehran Habibi and others, and I wanted to ask 2 questions. I sent an email to the address they quote in the book and get an undeliverable mail deamon reply. Do they not want to hear from readers anymore?

[Xie Ruchang]

Here is Max's profile.

[Morgan Bath]

So Max is Meharan Habibi? thanks

[Nicholas Cheung]

Hi Morgan,

So Max is Meharan Habibi? thanks

Yes. Max is the author of the book SCJD with J2SE 1.4.
Nick.

[Max Habibi]

Hi Morgan,
While I do answer personal emails, I prefer to discuss topics here, if it's the sort of discussion that the general population can benefit from. If not, then I'll look forward to your message.
All best,
M

[Morgan Bath]

I can cut and paste the email here if you want? Perhaps you already answered the worries I have in other threads here, but its often difficult as most searches I do deliver 1000 hits

[Philippe Maquet]

Hi Morgan,

I can cut and paste the email here if you want?

Good idea IMO. Most people on this forum use Max's book as a SCJD reference. Please refer to pages in the book, and ideally describe your questions with some (little) contextual information. I am pretty sure you'll get answers here, probably from Max himself, but from other ranchers as well.
Regards,
Phil.

[Morgan Bath]

Hi Morgan,

You can post this conversation on javaranch.
> Great book. Easy to read, and interesting too. However I do have 2
> questions:
>
> 1) Do you stand by your simple locking mechanism? I liked it, but after
> hanging about at javaranch I hear a lot of comments about having to store
> clientIDs to prevent dead threads deadlocking a record, or prevent a
> client
> unlocking a record it didnt lock. My assignment did not make any such
> demands, and im fairly happy justifying your simple approach as good
> enough
> IF you guys are still confident its a potentially 80/80 solution
I think the locking mechanism is sound for the DVD application, but it's
not a complete solution for the SCJD exam. Providing such would be
unethical.
We tried to come up with a scenario that required the same general journey
of discovery that the SCJD required without giving away the cookies.
Hopefully, we struck the correct balance. I've had probably over 50
private students score better then 95% on the SCJD, and at least as many
readers do so as well(the 95% bracket), so I think it's probably ok, at
least as a teaching tool.

>
> 2) Why does your DVDDatabase synchronize on 'this' for methods such as
> rent() after its already assured no other client can rent that DVD because
> its locked. For that matter considering each GUI gets its own DVDAdaptor
> which gets its own DVDDatabase why are you worried about locking on 'this'
> anyway?
Sorry, I don't have a copy of the book here, so I'll need the method(s).
>
> Sorry if these are idiot questions,
Not at all: I love these sorts of questions. I'm a geek's geek, so I could
talk about Threading all week.
>but I felt this was not totally
> explained in your book.
I'll have to do better in the next version <grin/>.
>Apart from these nagging doubts I feel very well
> prepared because of your book.
>
> thanks
>
> morgan
Good to hear. Drop me a note when you pass. And if you feel like reviewing
it on Amazon, I won't stop you.
All best,
M

[Morgan Bath]

Thanks for the reply Max.
On point two ill give an example:
DVDAdapptor method returnRental() starts by locking the DVD using the DVDDatabase method reserveDVD() which synchronises on the resevedDVDs object.
It then calls the DVDDatabase method returnRental() which synchronises on 'this' (the DVDDatabase). Each DVDAdapter has its own DVDDatabase, and it seems to me that means only one thread will be using that particular method on that object. Plus seeing as you have locked the DVD in question even if two threads did use this method on the same object, one would not be able to run it until the other thread released the DVD lock.
It seems synchronising on 'this' in DVDDatabase is irrelavant, and only serves to increase overhead.
Or am I winning the 'threading-doofus of the year' award?
Thanks, Morgan
(Dear Oracle ill never bitch about your products again!)
[ January 28, 2004: Message edited by: morgan bath ]

[Max Habibi]

Originally posted by morgan bath:
Thanks for the reply Max.
On point two ill give an example:
DVDAdapptor method returnRental() starts by locking the DVD using the DVDDatabase method reserveDVD() which synchronises on the resevedDVDs object.
It then calls the DVDDatabase method returnRental() which synchronises on 'this' (the DVDDatabase). Each DVDAdapter has its own DVDDatabase, and it seems to me that means only one thread will be using that particular method on that object. Plus seeing as you have locked the DVD in question even if two threads did use this method on the same object, one would not be able to run it until the other thread released the DVD lock.
It seems synchronising on 'this' in DVDDatabase is irrelavant, and only serves to increase overhead.

I'll look this over tonight and get back to you.

(Dear Oracle ill never bitch about your products again!)
[ January 28, 2004: Message edited by: morgan bath ]

lol
M

[Morgan Bath]

Any thoughts yet?

[Max Habibi]

Originally posted by morgan bath:
Thanks for the reply Max.
On point two ill give an example:
DVDAdapptor method returnRental() starts by locking the DVD using the DVDDatabase method reserveDVD() which synchronises on the resevedDVDs object.
It then calls the DVDDatabase method returnRental() which synchronises on 'this' (the DVDDatabase). Each DVDAdapter has its own DVDDatabase, and it seems to me that means only one thread will be using that particular method on that object. Plus seeing as you have locked the DVD in question even if two threads did use this method on the same object, one would not be able to run it until the other thread released the DVD lock.
It seems synchronising on 'this' in DVDDatabase is irrelavant, and only serves to increase overhead.

The issue here is that you want the client issuing a 'unlock' call to the same one that issued the 'lock' call. Per the RMI spec, it's not guaranteed that a given thread will interact with RMI in a predicable way. Thus, the DVD application chose to strictly define how that interaction would occur.
M

[Morgan Bath]

Originally posted by Max Habibi:

The issue here is that you want the client issuing a 'unlock' call to the same one that issued the 'lock' call. Per the RMI spec, it's not guaranteed that a given thread will interact with RMI in a predicable way. Thus, the DVD application chose to strictly define how that interaction would occur.
M

So this is a side effect of the simpicity in the locking solution? Am I correct in assuming that in a locking solution that stores the clients identity in some fashion (and only allows the locking client to unlock of course) this syncronisation on 'this' becomes redundant?

[Morgan Bath]

Oh whoa ... I just had a crappy thought:
I need to clear up what you are saying. If I have 2 clients (c1 & 2) connecting to the server through 2 remote objects (r1 & r2) which respectively hold references to Data objects (d1 & d2), are you saying its possible that the c1 thread might not actually have the same r1 and therefore d1 object each time? It migh lock using r1 and d1, but then unlock using r2 and d2? Tell me its just the threads that are not predictable, not the actually object references themselves
I had my lock manager using the Data object calling it as the client ID, which if I cannot guarantee that the client connects to the same Data object each time ... well screws me I supoose
And if so is it due to the 'pass by object' nature of RMI?

[Morgan Bath]

Actually I dont have to panic. If this is the case I can just syncronise on the LocalAdapter class I have. The RemoteAdapter uses an instance on LocalAdapter and all my book and unbook calls use the lock/modify/unlock mentality in sequence. If I make the book/unbook methods atomic at the local level, it wont matter if RMI juggles the references.
However this mean I cannot "enhance" the solution at a later date to allow locking of a record independant of the book/unbook functionality.

[Max Habibi]

Morgan, I'm getting a little confused here . What was the question?

[Morgan Bath]

To be honest I have a hard time understanding my own question when I re-read it
Im trying to understand the problem with RMI. I currently have the following:
GUI(MVC) connected via its controller to the RemoteAdapter. The RemoteAdapter has a LocalAdapter (similar to your DVDAdapter solution). The LocalAdapter connects to its own Data object. My Data Object uses a lockManager that stores the Data object so as to identify which client has the lock.
My solution assumes that EACH clients RemoteAdapter has its own LocalAdapter which in turn has its own Data. But you seem to be suggesting that I cannot assume this is true. That over RMI there is no guarantee that each connection from the client is made to the same Data object as last time - even though on paper it looks like each Data object exists only because the client created it, and therefore only it should have a reference to it.
Was that a little clearer?
[ February 03, 2004: Message edited by: morgan bath ]

[Max Habibi]

Originally posted by morgan bath:
To be honest I have a hard time understanding my own question when I re-read it
Im trying to understand the problem with RMI. I currently have the following:
GUI(MVC) connected via its controller to the RemoteAdapter. The RemoteAdapter has a LocalAdapter (similar to your DVDAdapter solution). The LocalAdapter connects to its own Data object. My Data Object uses a lockManager that stores the Data object so as to identify which client has the lock.

Ok, just to be sure we're talking about the same things here, how does Data interact with the LockManager? Is LockManager also a remote object? Does the Adapter have access to it? Is it a member of Data? Is it a singleton?
M

[Morgan Bath]

Single instance of LockManager shared between all Data objects. Either static in Data class or a singleton (currently both).

DO-IT-YOURSELF whiteboard:
---> means "creates a"
...> means "shares a single instance of"

GUI ---> Remote ---> Adapter ---> Data .....> LockManager
Basically can I guarantee the client GUI uses the SAME Data object for each call and can therefore be identified by this object to the LockManager? Or does having RMI break the chain. Perhaps Remote does not contact the same Adapter each time? I dont see how it can not, but thats my worry
oh.. all these objects are created at initialisation of the owning object ONCE, and ONCE only
[ February 03, 2004: Message edited by: morgan bath ]

[Morgan Bath]

Nevermind. Ran some extensive tests and my beutiful design works great for 1000 threads running 1000 times locally. Over RMI it totally bombs. Looks like im another cookie convert

[Max Habibi]

Sorry I haven't had time to get to this until now. Basically, the problem is this.
When RMI 'gives' your thread a remote object, it's only a loaner.
RMI might swap it out with another, equivalent, thread running that object at any point. Thus, you might think you're running under one thread, but it gets switched out from under you in the middle of execution. Those are the breaks of getting free remote objects.
I suggest that you use the cookie approach, because I think it's the intent of the testers that you do so: However, there are ways around this sort of thing in general. I don't have time to get into this right now, but I promise to soon.
All best,
M
ps - read your review on Amazon. Thanks
[ February 07, 2004: Message edited by: Max Habibi ]

[Stephen Galbraith]

So. let me join in this panic!
Is what you're saying ...
Client has remote Sever (i.e server implements Remote) object reference (obtained from a connection factory that extends UniCastRemoteObject), that we cannot "guarantee" that the Server refernce held in the Client may arbitrarly change to another instance of the Server Object that exist in another Client.
Is that right??

[Max Habibi]

Not quite, but DON'T PANIC
What, exactly, are you doing?
M

[Morgan Bath]

Implemented a simple cookie system that stores a static long in the Adapter class. Any client local or remote can ask for a cookie at any time.
Basically I now lock using lockManager.lock(int recNo, Object cookie);
Ive left the cookie as object so that I can use either my ClientCookie objects OR the Data object itself for any legacy programs using the DBMain specified lock(int recNo) - and that method simply calls lock(recNo, this). The legacy programs must be local for it to work but there is little I can do about that
My solution now works for upto about 50 client threads, each incrementing one of the fields 10,000 times each. As far as im concerned it works. Thanks for the input Max, BTW I put a review on amazon as you asked.

[Max Habibi]

I'm glad it's working. Btw, I noticed the review . Thanks for taking the time to post it.
All best,
M

[Stephen Galbraith]

Hi Max,
My design relies on separate instances of the Data class being given per client. I now have my buisiness methods defined on the server .
Anyway, I have a remote connection factory which I bind using RMI. This returns the buisness logic class exposed via a buisness logic interface that "extends Remote". Hence I though I was keeping a reference to a particular instance of the Buiness logic (which resides on the server) at the client.
But reading this thread made me doubt it.
Is the issue the "binding" process, that can return any similar objects?
If you can clear this up for me I'll get your new book on regular expressions!
Thanks, Steve

[Dixon Alexander]

He He He!

Max, I just got your book... I'm so happy...
I was gonna buy after completing the J2SE Exam...
Amazon has the sucker for $19.99 this is a chance for the whole forum to get a copy, after all you still get your share of the money right, Max?

[Dixon Alexander]

Max,
would it be appropriate to post a message letting everyone else know of the price of the book at this moment?

[Arun Subramanian]

Thanks for the very timely tip about Max's book, Dixon. 60% off rocks

[Max Habibi]

Originally posted by Stephen Galbraith:
Hi Max,
My design relies on separate instances of the Data class being given per client. I now have my buisiness methods defined on the server .
Anyway, I have a remote connection factory which I bind using RMI. This returns the buisness logic class exposed via a buisness logic interface that "extends Remote". Hence I though I was keeping a reference to a particular instance of the Buiness logic (which resides on the server) at the client.
But reading this thread made me doubt it.
Is the issue the "binding" process, that can return any similar objects?
If you can clear this up for me I'll get your new book on regular expressions!
Thanks, Steve

Hi Stephen,
In reading my own message again, I can see that I failed to be clear. What I meant to say was that you can never be sure which Thread is executing on behalf on your remote object.
Let me explain.
When you RMI creates a remote object for you, it uses a Thread, on the server, which caters to the calls made on that remote Object. Initially( on windows, anyway), you get a Thread per object. Eventually, however, the number of threads allocated get pooled, so that a Thread that was handling request for remote object X is now working for remote Object Y. Thus, you can't make assumptions about the Threads that are executing your code, server side. The actual remote Object is the same, but not the Thread it executes in.
Thus, your design sounds fine.
now will you buy the damn regex book?
M

[Max Habibi]

Originally posted by Dixon Alexander:
Max,
would it be appropriate to post a message letting everyone else know of the price of the book at this moment?

heck yeah! But not if I did it: that would be blatant advertising
M

[Stephen Galbraith]

Hi Max,
I'm off to amazon now!
Steve