Using COM as an encapsulation object

[runprn]

I manage a pretty massive intranet system that currently uses session state to hold the majority of a user's permissions, group access lists, preferences, etc. In the beginning, that approach worked fine, but now, we are reaching the point where the tax on server memory is affecting performance.

So, my three-part question is:

a) Is a COM object the best way to encapsulate data for an ASP/SQL 2000 application (not yet migrated to .Net).

b) Is their a non-binary/non-DLL way to go about this?

c) If not COM, then what?

I am loosely basing this on the idea of enterprise Java beans, but it may not be a valid comparison. Thanks for any suggestions! I've only used a few third-party COM objects, so this will be a newbie scenario.

 

[TJRTech]

You have broken the fundamental rule of web scalability...you have made stateful objects (and seek to make stateful COM objects).

Your current approach to stateful objects are to place things in session. As you are seeing, this doesn't scale.

You will have similar problems moving to stateful COM objects.

My recommendation, remove the state and put everything back in the database and query as you need it. In that way, your database and your connection to the database will cache things as needed. Especially if your database and web server are on the same box.

It sounds like JUST the wrong thing to do, performance wise, but it will give you the scalability you are looking for.

TR

 

[runprn]

I appreciate where you're coming from, but don't necessarily agree. In the Java model, for example, enterprise Java beans and/or other class objects are used exactly for this purpose: Encapsulating data so that return trips to the database can be avoided. There are pros and cons on either side of the debate.

Given that a full application re-write is not an option, I am still seeking an OOD-type of solution that can replace just the session objects. That would be a much simpler endeavor than rebuilding the entire application architecture. I have thought about writing "stateful" xml files to a temp directory, which may be an option. Client-side cookies, however, are not.

 

[TJRTech]

If the database and webserver are on the same box then its kinda a moot point because then, at certain point, everything is getting cached in memory and disk.

However, if the database and webserver are on different servers then avoiding the round-trip is a cost-savings I will agree.

Writing COM components that read the information from the database and persist that information locally to XML files might be one way to go, assuming the data is relatively static (like profile information). You could employ a simple read-through caching technique with a specified TTL (time to live) on the locally cached data.

In this way, you avoid the round-trip and still allow your COM components to be stateless (they get their state from the locally cached XML files).

Another consideration would be to deploy MSDE (Microsoft Data Engine...e.g. embedded SQL Server) on the WebServer and use it as the cache instead of XML. The same approach to TTL and read-through would apply, and then you could choose as similiar a data model as you like when compared to the source system.

Regards,
TR

 

[runprn]

Thanks, TR. It is a rather convoluted mess, with some session data static, and other data dynamic (depending on verious user-based actions). All told, there are between 10-20 session objects per session. Many are not instantiated until certain tasks are performed, and some are immediately expired after certain multi-step tasks have been completed.

Also, SQL Server does reside on a separate box. I have considered just caching everything in a SQL temp table, but there again, you would have to hit the database on every page hit. That's what I'm trying to avoid.

I will Google for TTL-related tutorials -- good suggestion. If you happen to know of any good links, please post them here.

Thanks, again!

 

[KiwiKelley]

Hello all, I'm in a pretty similar position to runprn, having inherited a large, COM-based web app that has not yet migrated to .Net. The existing programming team, who grew the app over 9 years, also violated the rule of web scalability, and made their COM objects stateful.

I was wondering if runprn found a solution, since I'm in a very similar position of not being able to re-write the code base, but the app must continue to work & function as we move eveything else over to .Net. I'm curious if the 'stateful' xml files option was chosen, and how that's worked, and would greatly appreciate pointers on any examples/articles folks might have,

Thanks a lot!

Kiwi Kelley
Univ. of Auckland,
New Zealand