By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,369 Members | 1,131 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,369 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Jul 19 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
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
-----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 ContextBoundObjectand use the [Synchronized] attribute.

My question is this. Would this completely serialize access or is there someway, still using ContextBoundObject, to effect something like theReaderWriterLock?

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
.

Jul 19 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.