Kuno Snaglers

Greenhorn
+ Follow
since Sep 28, 2005
Merit badge: grant badges
For More
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 Kuno Snaglers

I agree with you - I didn't think about this option. Anyway, it's almost done and I want to be on the save side this time:-}

THanks
Kuno
Hi Ailsa,

I just put down all the buiness logic to the server. I do following scenario in my book method:

# lock
# reread record from the db
# test if booked already
# update customer id
# unlock

I may also put the customer id verfication and 48h roule into the server.

Kuno
I don't know how they test it, but I failed because of the automatic failure. I guess they have a horde of indian students that test our application with a script or any else ;-}

Kuno
Nice to see that other people have the same troubles ;-}

I designed the client with implicit locking. Therfore, my client interface doens't provide any 'lock' or 'isLocked'-method. I just implemented an 'update', 'find', ..methods. These methods garantee atomic write access by using the 'lock' and 'unlock' of the Data Interface, but hide the locking from the client.

With my design choice I run into trouble when multiple users like to update the same record at time. I found a workaround by rereading the record and compare it with the record from the GUI-table. If these records don't equal, I show a message that the reccord is outdated.

There is still a little risk that both users success at the same time, however, it simplifies the implementation much.

I hope (;-}) that an explicit lock handling on the client is out of the assignement scope. I rather think about making a business layer with the appropriate business logic:
* lock
* test if already booked
* update
* unlock

However, I ran in the same naming interpretation confusion. I think, we just need to document it well, like we must do it for other decitions.

Good luck!

Kuno
You MUST implement this feature in a way!! I just failed because of the automatic failure....

I think the DB-Layer is not the place for and don't have a buisness layer. So, I will implement it in the Controller.

I'm thinking about hiding the other records that aren't within 24H. I don't see the point why the CRSs shall be able to see records in the past or more than 2 days in the future.

Kuno
As for the mentioned reasons of timeouts, I designed the client with implicit locking. Therfore, my client interface doens't provide any 'lock' or 'isLocked'-method.
I just implemented an 'update', 'find', ..methods. These methods garantee atomic write access by using the 'lock' and 'unlock' of the Data Interface, but hide the locking from the client.
With my design choice I run into trouble when multiple users like to update the same record at time. I found a workaround to reread the record and compare it with the record from the GUI-table. If these records don't equal, I show a message that the reccord is outdated.
Keep in mind: There is still a little risk that both users success at the same time, however, it simplifies the implementation much. I hope (;-}) that an explicit lock handling on the client is out of the assignement scope. I think, that's what Ailsa ment in his last reply ...? I'm right, Ailsa?

Thanks for your reply