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

Separation of data access and synchronitazion logic.

 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I am back from vacation and will bother you again with questions and ideas
One question:
It seems that most of you (at least in URLyBird assignement) had only one class Data where implementation of file access and and synchronization was provided.
I think that it makes much more sense to separate file access implementation and synchronitazion in two class. In these case synchronitazion and locking mechanism can be independant from file access logic (io/nio).
This question has nothing to do with the discussion of separation Data class and LockManager!
What I mean is following:
ThreadSafeData->Data instead of just Data with all synchronitazion inside).
Drawback of separation is that some flexibility in synchrontazion mechanism will lost since it can synchronize only on whole methods of Data.
Does it make sense to separate it?
Tx,
Vlad
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Vlad,
Welcome back. You wrote:

This question has nothing to do with the discussion of separation Data class and LockManager!
What I mean is following:
ThreadSafeData->Data instead of just Data with all synchronitazion inside).
Drawback of separation is that some flexibility in synchrontazion mechanism will lost since it can synchronize only on whole methods of Data.
Does it make sense to separate it?

How are you going to achieve this separation for the URLy Bird assignment? Seems like DBMain (or DBAccess) interface defines lock, unlock, and islocked methods which have to provide the defined functionality. The only way I know for providing thread-safety is by using synschronization. If you are talking about "deletation" to a specialized class, that sounds awfully close to an external lock-manager to me!
Regards.
Bharat
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I don't know about URLyBird, but looking at the instructions for Contractors (Bodgitt & Scarper) although the DB interface does have a number of specific requirements for its functionality, and there's a requirement that the whole program be thread-safe, it's not actually required that the thread safety be implemented inside the DB interface. It is, indeed, possible to put this in a separate class if you like. You could even make a second class which implements the same interface and is a synchronized wrapper for the main implementation - much like Collections.synchronizedMap() creates a synchronized wrapper object containing a normal Map inside. You could also put more elaborate sync logic in this wrapper class - e.g. it could contain read and write locking logic, or even a bunch of RecordLock objects for record-level locking. This is similar to my record-level locking on the cached Record object, except that a RecordLock object does not contain any data about the record other than whether it's locked or not, and what the cookie is (if your assignment uses cookies). And if you do use full caching, the Record objects are used only for record data, not for locking. Thus record locking can be completely independent of record caching.
Now, I don't know offhand if there's a compelling argument either way about whether this level of separation is desireable. I haven't implemented this sort of separation myself, and doubt I will; I don't see a need to refactor my classes again. But I'll certainly agree it's possible at least.
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad and Jim,
The only possible issue I see with this design is this one : SUN provided us with a DBAccess interface, asking us to implement it in a Data class. It may mean that they expect Data to be the entry point of any db access.
For another reason I have two layers too, but Data is the front-end :

People are still expected to use Data, as implicitly required (IMO) in the instructions.
Your ThreadSafeData --> Data chain is quite different : you'll probably use ThreadSafeData in your application and it's OK, but people who would use Data directly (as allowed in the instructions as a minimum : it's the only public class mentioned) will get in troubles.
Best,
Phil.
[ September 08, 2003: Message edited by: Philippe Maquet ]
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
What I ment is following:

Data class can be then used for a local mode and ThreadSafeData for network mode. If an IO implementation error occurs you work with Data class, if an thread handling problem occurs you work with TheadSafeData. It is a rule of a good OO design.
But it seems, that you do it all in one class Data for simplicitity.
Jim packs it in other classes used inside Data, but still Data is already thread-safe.
Right?
Best,
Vlad
[ September 09, 2003: Message edited by: Vlad Rabkin ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Vlad,
Right, but I don't do it just for simplicity, but also because I believe that using Data directly is an implicit requirement (see above). JMO !
Regards,
Phil.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
I believe that using Data directly is an implicit requirement...
you'll probably use ThreadSafeData in your application and it's OK, but people who would use Data directly

I don't think so. There is an interface and there two implementations(one is thread safe, another not).Both of them comply with specification of interface.
Whatever, your design makes my life much easier, since it is hard to separate these two classes. So, I will use your arguments for explaining why I have mixed these two thing together.
Tx,
Vlad
 
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 Vlad,
I think you are suggesting that Data becomes your Facade for all the database specific classes behind it.
Max and I have discussed this in the past as being one way to handle the locking requirements for those people who do not have cookies in their locking design :- they would have one instance of Data class per connected client (thereby giving them a unique item to store in their Maps) and each of these Data instances would connect to single instances of whatever other classes they need to do the real work.
I don't think there is anything in the requirements that prohibits this. Your Data class is still the access point to the database.
So although your reasons for doing this are different, I don't see a problem with the concept per se.
I also agree with your reasons for separating the responsibilites into dedicated classes.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic