Tom Nicki

Hi all,

I read little bit about samaphores which appeared in java 5.
Following sempahore
s = Semaphore(1, true);
created for each record would solve easly locing/unlocking problems.
No thread starvation problem because semaphores keeps threads in FIFO queue.
No need to think what is better: notify or notifyAll - there is no "wait" needed.

Does somebody of you use it?
Has anybody (using semaphores) got a good score in locking at the exam?
For me it looks too easy and I am getting suspicious.
In javadoc it is written that threads which cannot acquire semaphore will "lie dormant". Does this mean they consume "no CPU cycles"?

Greetings!
Tom

Hi,

Has anybody thought about following scenario:

- client connects to server and retrieves records
- server goes down and then goes up with a new data file and a new set of records
- client modifies a record

Is this problem solved somehow in RMI?
If not, do you care about it?

Tom

Second idea works fine, until there is no possibility to delete/create&reuse number.

Yes. I would have to assume I cannot reuse entries.

Fortunately, in URLyBird there are no such functionalities.

About create/delete.
I have read a few threads where it was written that even if your client program has no create/delete functionality, they should be implemented on the server/database side (and tested well).
I think problem still exists. Proper implementation and a strong argumentation is needed.

Tom

Hi Mihai

I think we do not have to create a new thread.
It is clear now and I have nothing to add.

Greetings,
Tom

Hi Robert,

My solution is only theoretical. I havent started implementing yet.
Maybe there is a weekness I haven't thought about.
I am wandering about your opinions.

For me problem does not exist in the database layer. I can simply create class implementing Sun's interface.
For instance imagine 2 oracle sql terminals where I call sql queries and modify the same record. The rule is the last one wins and updates the record.
It is the application above (in a business layer) which shoud take care about transactions, checking if the record i want to modify has been modified in the meantime.
I had 2 separate ideas/solutions:
1. I keep track what clients received by versioning. On the server I store version of each record and I send record always with version to clients. When client calls update I compare 2 versions: version from client and from server. If versions are the same, update is possible. If version is defferent -> exception.
2. I do not allow clients to update. I allow them to "book" which mean "set value of one field". Server just locks a record, checks if it is booked, books it (update one field), and unlocks it. No full update possible - no problem exists

Tom

Hi Mihai,

I think we will never finish this topic
I will try from the scratch and I give a simple example which shows our situation.
interface A { void a() throws Exc; } class Exc extends Exception { } class B implements A { public void a() {} // method does not declare any exception } public class C { public C() { A a = new B(); // (1) a.a(); // (2) } }

You have 4 possibilites now:
1. put line (2) in try/catch block and handle "Exc"
2. you declare class "Exc extends RuntimeException"
3. in line (1) you use "B a = new B();"
4. You do not create class C at all
I described more-less pluses and minuses of solutions 1,2,3 and I cannot imagine solution 4 is not possible.

As you wrote somewhere before you "chosed not to throw any DuplicateKeyException". I guess it means your class implementing DBMain does not throw DuplicateKeyException and of course it is possible in Java (I assume you have something like class B in your sources).

And here I started to ask about your implementation and how "your class C" works. Which point (1/2/3/4) fits to your sources?

Is there any other way?

Maybe we should swich to priv emails? I have doubts it is interesting for anybody except us

Tom

My interpretation 48hours is that you can book a rooms with today's and tomorrow's date.
I am thinking also about giving a user possibility to book all future date rooms and it can be up to a user what he books (I mean: I am able to book everything but our company only accepts booking of rooms within next 2 days).

Tom

Calling functions on the interface does not require me to know what kind of object it is. It can be Data. It can be also OracleData, XFileData etc.
It allows to use Facade, Factory patterns where a common parent (interface or class) is needed. It is just a question of polymorphysm and all its advantages.
And here comes the problem with DuplicateKeyException because calling createRecord on the interface requires to handle it.
If you use
Data d = new Data();
it probably makes your server implementation sticked to Data accessor.

It is your decision. Maybe correct one because easier to implement.
I still have some doubts.

Tom

What do you think about following code:

package suncertify.db; public class Bc { public Bc() { DBAccess d = new Data(); d.createRecord(new String[] {""}); } }

I guess you do not use it in this way.

Tom

As you can see here is a must so I don't like to take any risk.

Ok. You are right. I will not risk it too

What you mean by :
easy search panel (name, city, and/or)

I meant search window (or something) which appear after pressing search button. I guess there should be more options in order to increase user friendlyness espaecially when all file records can appear in JTable.

is a business rule and the client only use it not to alter it. Also if any client has his own rule you must transport first the
whole search result from server to the client and then to filter it (using the client specific rule).

Iteresting idea
but I thought rather about server side business rules which can be used by client programs. Server provides ready results.

P.S : I think that we go away from this thread topic, how about a new thread about the 48 h thema.

If you think there will be much more to discuss - go agead.
On the other hand we are still discussing search GUI

Tom

Hi Mihai,

Let's say you implement
DuplicateKeyException extends RuntimeException
and your code does not care about it.

Let's say there is a need to implement additional database accessor where keys are provided.
DuplicateKeyException gets important and it should be handled. How can you force that it will be handled by application using your new accessor?
Only by implementing DuplicateKeyException as checked exception but this destroys your previous application.

Du you want to copy/paste your interface to a new package implementing all exceptions from the scratch? I think interfaces should be reusable. Exceptions used in interface should be reusable as well.

BR Tom

Hi Mihai,

How you can be shore about the CRS intends ?

I am not sure. My interprettion comes form the problem description.

They (CSRs) take bookings only within 48 hours of the start of room occupancy.

It is not said you must take care about 48H in your GUI. It is not said you should do it. I guess it is good what you decide and well argue.

My idea is:
Only records from next 48H frame are shown to the CSR (now<records<now+48H).

My argumentation (plus/minus):
+ it fits to this room broker company (48H is what they only do)
+ client works faster (less data to get from server)
+ easy search panel (name, city, and/or)
- CRS cannot see historical data (does he need it? it can take forever to get all historical data)
- CSR cannot see ">48H" records (but what shall he do with it? book it? this company does not do it.)

My implementation:
48H is set on client side. Easy to change or add to search if it is wished.

I think that by default the table can be empty.

For me it would look really strange.
What will be the first thing that almost every user does when he connects?

Tom

I think that SUN does this with puropose - I mean to omit the primary key.
IMHO the primary key depends on your Data layer logic.
You can calculate/generate one using the record information and your Data logic.
By example (I have the URLyBird) on my case it make sense that a record apears two times in the database - because a hotel can have more than one room with the same attributes,

I agree.

so I chose not to throw any DuplicateKeyException.

Here I am not so sure.

Here is my interpretation:
On the one hand we must implement flexible solution which will easly allow relpacing db file to e.g. oracle where maybe rows have keys.
On the other hand our db file solution does not need DuplicateKeyException.
We could:
1. DuplicateKeyException extends RuntimeException
... and forget about it. If "junior programmer" will ask about it one day, we say "that's the bloody requirements we had to trick somehow".
2. Try to handle it even if it is not possible by our code to throw it keeping in mind that other db solutions can use it.

I lean more towards second solution.

Tom

No records. I've been weighing my options, but I believe this to be the better approach. Imagine the database becomes bigger. If you start with all records, you'll transfer a lot of information that noone wants to see anyway.

I thought about setting default search options (like 48 checkbox) and initialize first view with such results.
One of my ideas is to not even give possibilities to choose 48 hours or something else. Just display "48 hours" all the time (filtered by search).
Do you think it is "requirements risky"?

plus/minus:
+ this is what CSRr need
+ not so much data transfered by each request
- risk it does not fit to requirements


Tom

Hi Miles,

I have the same solution. I thought rather about using record order number than offset but this make no difference.

What about "possibly reusing a deleted entry" and "DuplicateKeyException" in
// Creates a new record in the database (possibly reusing a // deleted entry). Inserts the given data, and returns the record // number of the new record. public long createRecord(String [] data) throws DuplicateKeyException;
Do you have it in your assignment? What solution do you have for it?

Tom