multi-threading issues, ideas to solve?

  • Thread starter Thread starter Peter Row
  • Start date Start date
P

Peter Row

Hi,

I have a VB6 webclass app that was ported to VB.NET.
However due to multithreading now being used the global variables used have
come to haunt me.

Problem:

I have a handful of global variables:
A asp context wrapper object
A database wrapper object
A couple of others.

The reason that the context and db access objects are global is because a
lot of functions, methods etc...
need to use them and passing them in having creating them locally would be
ridculous.

i.e. I have the following functions/sub,

FuncA()
....some code
SubB()
.....more code
End Func

SubB()
....some code
..... asp context object usage
.... more code
....FuncC()
End Sub

FuncC()
.... some code
.... data access object usage
.... mode code
End FuncC()

Therefore in order for this to work the definitions would need to be:
FuncA( AspContext, DatabaseWrapper )
SubB( AspContext, DatabaseWrapper )
FuncC( DatabaseWrapper)

.... which to me is absolutely ridiculous. FuncA() doesn't use any of the
params it has,
SubB only uses one of its parameters.

This would be a nightmare, even if I made a containing structure that had
each of the objects.

Is there anyway that I can have object variables that are visible to all my
other funcs/subs/methods
but are local to the currently executing thread?

Regards,
Peter Row
 
You are basically asking for another global variable to get around the
parameter passing which is what got you in this mess to begin with. You
should either use the parameter passing, which i don't understand why you
think it is ridiculous, or you should restructure your code to break the
dependency of function a, b, and c. This would involve making it more
granular, which it isn't.

This sort of problem is commonly caused by incorrect logic structuring in a
routine. Functions should implement one task, that is they should be as
granular as possible with regard to this task. As soon as you start rolling
out functions which encompas multiple tasks, you start creating dependencies
which ultimately lead to tightely coupled functions.
 
Hi,

The example of the func/sub A, B, C thing was not necessarily what my code
is
doing.

Plus I understand that 1 func should do one task. But surely depending on
what the 1 task is you might have to break it up into more specialised
subs/funcs
to maintain the cohesiveness of it.

For example say you had a ProcessOrder() function the data for which will go
to and from a DB, would you have the DB access routines in ProcessOrder()
along with the business logic? Well I would not since the DB access would be
common to lots of areas of the system containing ProcessOrder() except
different
SP,params, and it doesn't make sense to repeat the same code over and over.

Regards,
Peter
 
Back
Top