Page 1 of 1

[56K WARN] couple of questions on design issues

Posted: Thu Jan 11, 2007 5:10 am
by raghavan20
i too apologize for the bad title :?

i tried to explain most of the things in the logical model of the sample problem.
Image



lets say there is a main interface to this system called WorkDelegator which is responsible for doing a process and a process may involve a set of subprocesses. It calls Worker1 or Worker2 or Worker1 and Worker2 to do some work for it. The worker1 and worker2 need some data to get the work done. each worker class is given a model to get its data. the model class does not create database connection but the DBFactory class instantiates these models and provide them db connections.

please ask me if you have doubts regarding the situation here.

now the questions are,
1. a sample work might be performed like this:
WorkDelegator calls Worker1's process()
Worker1 calls DBFactory's getModel() to get WorkerModel1
Worker1 calls WorkerModel1's load() to get data
Worker1 performs some function with the data

..
..

there can be any number of workers and any number of workers can be called by main WorkDelegator depending on the work to be performed. No worker here knows about other workers working to solve the bigger process as this is managed by WorkDelegator.


the WorkDelegator is very often called in real time to do some work and it does the work with the help of worker classes. we use singleton for db connection in DBManager class to use same connection for all model classes but everytime WorkDelegator is called, atleast one connection is created which is not closed. Now, how can we close the db connection?


2. are there patterns in here?
2.1. the WorkDelegator gives some work to Worker1 and Worker2. is this a pattern?
2.2. the DBFactory actually creates those models so is this factory pattern?

Posted: Thu Jan 11, 2007 6:23 am
by timvw
I would expect your WorkDelegator to pass a Transaction (Context) handle to all the Workers it dispatches too... With that Transaction (and the data it already recieves) the DBFactory can decide what is needed exactly.

Once the workDelegator notices that all Workers have completed, the WorkDelegator can notify the DBFactory that the Transaction can be completed (or connections closed...)

Posted: Thu Jan 11, 2007 6:34 am
by raghavan20
timvw wrote:I would expect your WorkDelegator to pass a Transaction (Context) handle to all the Workers it dispatches too... With that Transaction (and the data it already recieves) the DBFactory can decide what is needed exactly.

Once the workDelegator notices that all Workers have completed, the WorkDelegator can notify the DBFactory that the Transaction can be completed (or connections closed...)
that is a very good idea...thanks timvw

Posted: Thu Jan 11, 2007 7:55 am
by Maugrim_The_Reaper
2. are there patterns in here?
2.1. the WorkDelegator gives some work to Worker1 and Worker2. is this a pattern?
2.2. the DBFactory actually creates those models so is this factory pattern?
Um...does that need an answer besides "Yes"? ;)

DBFactory handle creational logic, hence it's the Factory Pattern. It's manufacturing a Model based on some input (or context data) passed to it from an external source. Not sure if WorkDelegator follows an exact pattern - might be considered a Delegate Pattern. All it seems to do is accept a method call from outside, then setup a workflow, and delegate specifics to whichever workers it decides are needed. Simple delegation...

Posted: Thu Jan 11, 2007 8:04 am
by raghavan20
Maugrim_The_Reaper wrote:
2. are there patterns in here?
2.1. the WorkDelegator gives some work to Worker1 and Worker2. is this a pattern?
2.2. the DBFactory actually creates those models so is this factory pattern?
Um...does that need an answer besides "Yes"? ;)

DBFactory handle creational logic, hence it's the Factory Pattern. It's manufacturing a Model based on some input (or context data) passed to it from an external source. Not sure if WorkDelegator follows an exact pattern - might be considered a Delegate Pattern. All it seems to do is accept a method call from outside, then setup a workflow, and delegate specifics to whichever workers it decides are needed. Simple delegation...
normally before we know design patterns, we try to do our best in logical modelling of classes but at that stage we are unaware that some parts of the design may contain one or more design patterns. when at a stage where we started to know about patterns but still not too familiar, we can see many parts of our logical modelling may contain design patterns but cannot really confirm whether they conform to the requirements of those patterns. These doubts keep cropping up until one gets very familiar with patterns in real applications.

Thanks maugrim.

Posted: Thu Jan 11, 2007 10:30 am
by raghavan20
timvw wrote:I would expect your WorkDelegator to pass a Transaction (Context) handle to all the Workers it dispatches too... With that Transaction (and the data it already recieves) the DBFactory can decide what is needed exactly.

Once the workDelegator notices that all Workers have completed, the WorkDelegator can notify the DBFactory that the Transaction can be completed (or connections closed...)
will it be alright if i declare a __destructor() in Work Delegator and make a call to DBFactory class's deleteConn() as show in below diagram ?

Image

Posted: Thu Jan 11, 2007 11:20 am
by Maugrim_The_Reaper
Is it necessary to close the connection? Just wondering, seemed in your opening post you were having problems with an unexpected new connection being opened...

If it's unexpected - the connection is being handled outside DBFactory or am I wrong and DBFactory is creating a new connection for some reason? If it's a Singleton maybe check whether you're actually reusing the singleton instance -

Posted: Thu Jan 11, 2007 2:42 pm
by raghavan20
Maugrim_The_Reaper wrote:Is it necessary to close the connection? Just wondering, seemed in your opening post you were having problems with an unexpected new connection being opened...

If it's unexpected - the connection is being handled outside DBFactory or am I wrong and DBFactory is creating a new connection for some reason? If it's a Singleton maybe check whether you're actually reusing the singleton instance -
maugrim, WorkDelegator does a unified process by splitting up the unified process into set of works that are assigned to worker1....workern but worker1...workern need data to process. so those workermodel1..workermodeln are created to provide the data but these models need db connection to work on.

since these models are created by DBFactory, it is responsible for instantiating these model classes and providing them with db connection. actually the DBFactory, uses singleton to reuse the same db connection for all model classes.

the worker1..workern will not close db connection because there still might be other workers working for the unified process and incase each worker closes its own, then singleton is of no use, as we have to keep opening and closing connections all the time. but if worker1..workern do not close the db connections then who will close this one db connection created each time the whole unified process is started by WorkDelegator.

then timvw told me that if WorkDelegator is aware when all the work is done then we should put the responsibility to that class. so what i did is i built a __destruct() method in WorkDelegator which actually makes a call to DBFactory asking to close the open DB connection. and when control goes out of WorkDelegator, the db connection is closed.

i hope this helps.

Posted: Thu Jan 11, 2007 4:53 pm
by Maugrim_The_Reaper
That makes sense to me now :).