If you can take a look at the book "Transactional COM+" by
Tim Ewald. He has some good advice in building scalable
architectures, it mostly is about COM+ but applies to
what you are trying to do.
Basically it goes against what you are trying to do. He is
not the only one I have read that goes against this
architecture either, in both the Java and MS world. You
have the ability for ReaderWriterLock at the DB level
using transactions and could even push it out to the COM+
level use its transactional capabilities, so there is no
reason for a developer to come along and duplicate it at
the object level with the use of threads.
- J
>-----Original Message-----
>My architecture is, (ala Fowler PoEAA)
>
> Presentation Layer
> |
> Service Layer
> |
> Problem Domain
>(My Business Objects are held in memory)
> |
> Persistence Layer
> |
> Physical Storage
>
>It is the aim that business objects be accessed by many
threads at once.
>There will be many more reads than writes. I will need to
lock the object(s)
>when they are being written but not when they are being
read. I will also
>need to provide some kind of transactional support.
>
>One of my ideas was to derive all business objects from
ContextBoundObject
>and use the [Synchronized] attribute.
>
>My question is this. Would this completely serialize
access or is there some
>way, still using ContextBoundObject, to effect something
like the
>ReaderWriterLock?
>
>Also, on a different track, does anyone see problems with
maintaining large
>numbers of business objects in memory assuming RAM can be
added if
>necessary.
>
>Robert Zurer
>
>
>.
>
|
Similar Threads
