Best practice? Managing concurrent access to Business Objects on the middle-tier

[Robert Zurer]

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

 

[JD]

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