Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lock cookie not sent to client

 
Filipe Fedalto
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I assume most of you lock and unlock the database file/record from the client. (Am I wrong with this assumption?) This leads to a design where the lock cookie is also known to the client.

Would it be better design whether the lock cookie be kept inside the server? Just like it is in a real DBMS. This way the client would just have remote access (rmi or sockets whatsoever) to high-level data-access functions. (read, find, update...)

What do you think?

Or otherwise stated: would it be a major design flaw not to have the clients know about this lock cookie or the entire locking mechanism at all?

Thank you all in advance,

Filipe Fedalto
Java Instructor and Consultant
Cafe' Javanes - www.cafejavanes.com.br
Brasil
 
Filipe Fedalto
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I really think my design is an interesting approach, especially if lock() and unlock() are automatically called from the other data-access methods (write, update...).

My point is: if they are called automatically, why to have the client bothering on them?

Regards,

Filipe Fedalto - Brasil
Java Instructor and Consultant
Cafe Javanes - www.cafejavanes.com.br
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are proposing a 'thin client' with the buiness logic on the server that hides the locking from the client.

Good! We are a rare breed at present.

I have it on good authority that this is a valid approach that shouldn't be penalised. That is as long as your spec does not specifically prevent it.

If you give it a little more thought and let us have some ideas.

Here is one to mull over:

Consider that wrapping the String[] data returned by Suns interface in a Record object that includes business logic.
Consider that a Record object is more applicable in the design of thin client architecture than a fat one.
 
Filipe Fedalto
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Mike,

This is exactly what I first did, when starting to deal with the Data class. I actually created a class named Record (yep, exact name) that wrapped the String[] data.

I agree with you. I wouldn't say that I am an extreme fan of thin clients, as there are some situations where a fat client is a must. (e.g. Online 3D 1st person shooter network based games)

However, as to this URLyBird assignment, the thin client would just do it.
As the common rule says: Keep It Simple...

On the other hand, my first option was plain sockets (because I'm no fan of RMI and because I love sockets). I shifted towards RMI for the sake of laziness.

However, I am already regretting my decision. If I were implementing just the network communication, RMI would just be fine. On the other hand, it's just ok to program the direct access stuff.

What is annoying me is the cohexistence of these two requirements. In order to have an abstraction of these two paths in the client layer there seems to be one to many redundant interfaces and proxies, all very similar to the DB.java interface.

The scenario is: client doesn't see server, either RMI or direct, but only an interface. However, there is also a remote interface and also the provided DB interface, all three of them very similar.

If I have disclosed too much of my personal design, moderators, please forgive me and cut the necessary stuff out.

Best regards,

Filipe Fedalto - Brasil
Java Instructor and Consultant
Cafe Javanes - www.cafejavanes.com.br

What do you think of it?
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Filipe Fedalto:
Hi, Mike,

The scenario is: client doesn't see server, either RMI or direct, but only an interface. However, there is also a remote interface and also the provided DB interface, all three of them very similar.

If I have disclosed too much of my personal design, moderators, please forgive me and cut the necessary stuff out.

What do you think of it?


Well the DB interface has been thrust upon us, I really do think the main purpose is for Sun to automate testing on the submission, not particularly to make us deal with a real life style client wants x, y, z scenario.

With that in mind, I am largely ignoring it for my design. I have eventually decided to create a sub interface from it. And I have business interface for remote/local connection and a back end DataAccess interface that is employed decorator fashion for the RAF, & cacheing classes.

So yes there are similar interfaces floating about, but they are different and they do different jobs, so I'm fairly happy about that.

On a different note, there is mention in other threads about tracking client threads, for locking records. I can't see that being necessary, especially for thin client. But I am a bit weak in that area.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by mike acre:

Well the DB interface has been thrust upon us, I really do think the main purpose is for Sun to automate testing on the submission, not particularly to make us deal with a real life style client wants x, y, z scenario.

With that in mind, I am largely ignoring it for my design. I have eventually decided to create a sub interface from it. And I have business interface for remote/local connection and a back end DataAccess interface that is employed decorator fashion for the RAF, & cacheing classes.

So yes there are similar interfaces floating about, but they are different and they do different jobs, so I'm fairly happy about that.

On a different note, there is mention in other threads about tracking client threads, for locking records. I can't see that being necessary, especially for thin client. But I am a bit weak in that area.



Client tracking, whether by thread or by some other means is only needed if you want to be able to handle abandoned locks and disconnected clients. These are not real issues in the thin client scenarios.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Filipe,

You are certainly not alone in considering a thin client solution, and many candidates have passed using such a solution.

If you would like to read some arguments for and against such a solution, then you may like to read the (long) thread "Should lock methods be callable by the client".

Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic