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 ContextBoundObj ect
and use the [Synchronized] attribute.

My question is this. Would this completely serialize access or is there some
way, still using ContextBoundObj ect, to effect something like the
ReaderWriterLoc k?

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 "Transactio nal 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 ReaderWriterLoc k 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 alsoneed to provide some kind of transactional support.

One of my ideas was to derive all business objects from ContextBoundObj ectand use the [Synchronized] attribute.

My question is this. Would this completely serialize access or is there someway, still using ContextBoundObj ect, to effect something like theReaderWriterLo ck?

Also, on a different track, does anyone see problems with maintaining largenumbers of business objects in memory assuming RAM can be added ifnecessary.

Robert Zurer
.