using AJAX when class instances get disposed after load

P

PJ6

AJAX is great, but in order to reference specific class instances
server-side, I have to maintain a static function to return them from a
unique identifier. Only... the consumer controls themselves get disposed
after the page loads! The object(s) I'm concerned with are not controls
themselves, but now I'm faced with trying to decide when to dispose them
without being able to pay attention to disposal of the consumers.

I suppose I could persist a single instance of each kind of class instanace
in memory, but I'm worried that I'd then have to make all of them
thread-safe.

I'm sure I'm not the first person to run across this problem. Any
sugestions?

TIA,
Paul
 
A

agapeton

You could use Atlas. It allows you to dynamically access web services
via ECMAScript (JavaScript). Since you are using a system with
explicit components, you should probably be tapping into the SOA world.
Using a SOA approach, you don't rely on controls, but components
(services in this case).

Doing a poor-mans cache (static object) is another way to get things
done. I'll never recommend Application[] persistence due to it's
limitations though.

You may also want to look at my Png64 Server example on my blog below
(Firefox only). It's an example of how you can use remote scripting
(what is being called Ajax now adays) to access a remote page in a SOA
fashion without atlas and without web services. The server is just an
aspx page throwing back XML. The browser (modern browsers as well as
IE can do this) then parses the XML and you get your data.

David
http://www.davidbetz.net/dynamicbliss/
http://www.davidbetz.net/winfx/
 
B

Bruce Barker

ajax doesn't change the request/response nature of websites. it just browser
client code making a server call (which should be stateless), and using
dhtml to display results.

-- bruce (sqlwork.com)
 
P

PJ6

Hmmm. Maybe I should back up a bit before I make this too complicated.
You're right, the server calls should be stateless. That means that the DB
updating mechanism I'm using should be as well if I'm doing remote
scripting. Time to tweak the design a bit...

The simplest design does not persist data in consumer objects but rather
just recreates them every time an updating call is made. I don't like this
because technically I could use a chaching mechanism. But I can put that in
later. "Never optimize a prototype".

Guess that solves my problem with multithreading... I'll just avoid any
design that requires it.

Thanks,
Paul
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,905
Latest member
Kristy_Poole

Latest Threads

Top