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

Is ArrayList in application object are thread safe?

P: n/a
Hi,

I want to keep a list of my visitors in an ArrayList which I place in the
application object like this:

Application("Visitors") = new ArrayList(); // The list of visitors

Then, each visitors update their own information in that list for every page
they visit.

Also, I add and remove visitors from the list as they come and go.

Can this cause concurrency situation and corrupt data? Do I need to lock the
Application("Visitors") each time I access it to add or to remove? Wouldn't
that be too much in term of performance? what is the best way to do this?

Thanks for any tips!

Stephane
Nov 19 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
On Tue, 4 Oct 2005 10:45:03 -0700, "Stephane"
<St******@discussions.microsoft.com> wrote:

Can this cause concurrency situation and corrupt data? Do I need to lock the
Application("Visitors") each time I access it to add or to remove? Wouldn't
that be too much in term of performance? what is the best way to do this?


Yes, Stephane. You'll need to take care when modifying the list
itself. If the modifications are not done in a thread safe manner you
can end up with a corrupt list and strange runtime exceptions.

One approach is to use the thread safe ArrayList wrapper returned by
the Synchronized method. This makes your work easy, but may not be
what you need.

The synchronized wrapper makes individual operations thread safe, but
you might have code like this:

if(list.Count > 0)
Visitor v = list[0] as Visitor;

The problem with the above is that another thread might remove the
last visitor from the list between the time you check the Count
property and the time you retrieve the object with the [] indexer.
You'll get an exception.

The safest approach is to lock the list anytime you read or write:

lock(list.SyncRoot) {
// use the code above
}

.... and of course the safest approach is not going to be the most
performant approach.

Starting out, I would favor safety over performance, and run tests. In
most applications these locks won't kill performance. You can use
finer grained locks, or reader versus writer locks for more
throughput, but these add complexity.

If you do run into trouble I'd seriously consider storing the
information in a database. Relational databases excel at concurrency
management and fine grained locking.

Hope this helps,

--
Scott
http://www.OdeToCode.com/blogs/scott/
Nov 19 '05 #2

P: n/a
Hi,

Thanks for your answer, it was helpful!

You think that managing visitors in a DB would be a more convenient way? I
thought it would be faster and simplier using application object.

Thanks,

Stephane
"Scott Allen" wrote:
On Tue, 4 Oct 2005 10:45:03 -0700, "Stephane"
<St******@discussions.microsoft.com> wrote:

Can this cause concurrency situation and corrupt data? Do I need to lock the
Application("Visitors") each time I access it to add or to remove? Wouldn't
that be too much in term of performance? what is the best way to do this?


Yes, Stephane. You'll need to take care when modifying the list
itself. If the modifications are not done in a thread safe manner you
can end up with a corrupt list and strange runtime exceptions.

One approach is to use the thread safe ArrayList wrapper returned by
the Synchronized method. This makes your work easy, but may not be
what you need.

The synchronized wrapper makes individual operations thread safe, but
you might have code like this:

if(list.Count > 0)
Visitor v = list[0] as Visitor;

The problem with the above is that another thread might remove the
last visitor from the list between the time you check the Count
property and the time you retrieve the object with the [] indexer.
You'll get an exception.

The safest approach is to lock the list anytime you read or write:

lock(list.SyncRoot) {
// use the code above
}

.... and of course the safest approach is not going to be the most
performant approach.

Starting out, I would favor safety over performance, and run tests. In
most applications these locks won't kill performance. You can use
finer grained locks, or reader versus writer locks for more
throughput, but these add complexity.

If you do run into trouble I'd seriously consider storing the
information in a database. Relational databases excel at concurrency
management and fine grained locking.

Hope this helps,

--
Scott
http://www.OdeToCode.com/blogs/scott/

Nov 19 '05 #3

P: n/a
WJ

"Stephane" <St******@discussions.microsoft.com> wrote in message
news:12**********************************@microsof t.com...

You think that managing visitors in a DB would be a more convenient way ?
For stability, DB such as MS/SQL Server is recommended
I thought it would be faster and simplier using application object.


Yes, RAM is always the fastest regardless of what you do. Simply, because no
IO involved.

John
Nov 19 '05 #4

P: n/a
On Tue, 4 Oct 2005 11:54:00 -0700, "Stephane"
<St******@discussions.microsoft.com> wrote:
Hi,

Thanks for your answer, it was helpful!

You think that managing visitors in a DB would be a more convenient way? I
thought it would be faster and simplier using application object.


It might still be simpler to keep an object around in the Application
object, but remember if your web application resets you'll loose all
the information, that is another advantage to using a database.

--
Scott
http://www.OdeToCode.com/blogs/scott/

Nov 19 '05 #5

P: n/a
A hybrid approach might also be an option. Use the database as the
underlying store, and spin it up on application start, but from there,
do all your user actions could be in memory ... this reduces your load
on the database (making it more performant for other needs.)

Another fairly simple approach that might provide benefits is to create
your own class that wraps an ArrayList and internally use a
ReaderWriterLock object to provide finer grain locking around the
methods of ArrayList that you need. This could also have the benefit if
encapsulating the logic for writing updates to the database and spinning
itself up.

Stephane wrote:
Hi,

Thanks for your answer, it was helpful!

You think that managing visitors in a DB would be a more convenient way? I
thought it would be faster and simplier using application object.

Thanks,

Stephane
"Scott Allen" wrote:

On Tue, 4 Oct 2005 10:45:03 -0700, "Stephane"
<St******@discussions.microsoft.com> wrote:

Can this cause concurrency situation and corrupt data? Do I need to lock the
Application("Visitors") each time I access it to add or to remove? Wouldn't
that be too much in term of performance? what is the best way to do this?


Yes, Stephane. You'll need to take care when modifying the list
itself. If the modifications are not done in a thread safe manner you
can end up with a corrupt list and strange runtime exceptions.

One approach is to use the thread safe ArrayList wrapper returned by
the Synchronized method. This makes your work easy, but may not be
what you need.

The synchronized wrapper makes individual operations thread safe, but
you might have code like this:

if(list.Count > 0)
Visitor v = list[0] as Visitor;

The problem with the above is that another thread might remove the
last visitor from the list between the time you check the Count
property and the time you retrieve the object with the [] indexer.
You'll get an exception.

The safest approach is to lock the list anytime you read or write:

lock(list.SyncRoot) {
// use the code above
}

.... and of course the safest approach is not going to be the most
performant approach.

Starting out, I would favor safety over performance, and run tests. In
most applications these locks won't kill performance. You can use
finer grained locks, or reader versus writer locks for more
throughput, but these add complexity.

If you do run into trouble I'd seriously consider storing the
information in a database. Relational databases excel at concurrency
management and fine grained locking.

Hope this helps,

--
Scott
http://www.OdeToCode.com/blogs/scott/

Nov 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.