Re: [ACFUG Discuss] Issue --- Transaction (Process ID 136) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transactio

[Greg McTure]

You can copy one of the update statements that you are using inside the sproc 
(stored procedure) into the query analyzer and see the execution plan for the 
update query.  If the columns of the WHERE clause is in an index see if than 
index is being utilized in the execution plan.

Also, do you get the deadlock issue in all of your environments (i.e. dev, 
test, and prod) or just in prod?

Greg McTure

-Original Message-
From: Ajas Mohammed 
Date: Tue, 26 Jan 2010 22:17:03 
To: 
Subject: Re: [ACFUG Discuss] Issue --- Transaction (Process ID 136) was 
deadlocked on lock | communication buffer resources with another 
process and 
has been chosen as the deadlock victim. Rerun the transaction.

Hi Greg,

I will try to answer to the best of my knowledge.

There are 407359 records in the table. There is only 1 record being updated.

Not sure if its full table is being locked or not.

Do you have the ability to analyze the actual statement to get an execution
plan?
Well, let me see if I understand this first. Do you mean to say, I can copy
the stored proc code in sql query analyzer and run the stored procedure code
and see the execution plan perhaps?


http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it represents
the wise choice of many alternatives.


On Tue, Jan 26, 2010 at 9:45 PM, Greg McTure  wrote:

> Hi Ajas:
>
> It may be helpful to see a section of your stored procedure code that is
> doing the updates.  Also, approximately how many records are in each of the
> tables being updated and approximately how many records are being updated?
> The SQL engine or optimizer may behave differently depending on the database
> brand (i.e. Oracle, MSSQL, Sybase, MySQL, etc); however, generally speaking
> if the predicate of your WHERE clause covers most of the records in your
> table then the optimizer will complete a full table scan even with the
> presence of the indices.
>
> I would also consider looking to see if the full table is being locked on
> the updates.  This should not be happening but it is just another angle to
> check out.  I would not think this would not be an issue since I know in
> Oracle even if you are updating an entire table only the current row will be
> locked during the update.
>
> I don't see anything off-hand with your update statements.  One can expect
> the best performance by updating the table with a single statement instead
> of multiple statements unless of'course you have so many records that your
> rollback segment becomes too small to support the number of records to be
> updated.
>
> Do you have the ability to analyze the actual statement to get an execution
> plan?
>
>
> On Tue, Jan 26, 2010 at 11:30 AM, Ajas Mohammed wrote:
>
>> Hi Greg,
>>
>> I found the stored proc which results in deadlock situation. It has lets
>> say about 10 updates like this
>>
>> update tbl set col3 = someval where col1 = @col1 and col2 = @col2
>>
>> update tbl set col4= someval where col1 = @col1 and col2 = @col2
>>
>> update tbl set col5 = someval where col1 = @col1 and col2 = @col2
>>  and so on for other cols 6-10.
>>
>> col1 and col2 are part of clustered index.
>>
>> I can share the code off the list.
>>
>> Thanks for your input. Makes lot of sense to get started with
>> troubleshooting.
>>
>> 
>> http://ajashadi.blogspot.com
>> We cannot become what we need to be, remaining what we are.
>> No matter what, find a way. Because thats what winners do.
>> You can't improve what you don't measure.
>> Quality is never an accident; it is always the result of high intention,
>> sincere effort, intelligent direction and skillful execution; it represents
>> the wise choice of many alternatives.
>>
>>
>>
>> On Fri, Oct 30, 2009 at 5:14 PM, Greg McTure  wrote:
>>
>>> Hi Ajas.
>>>
>>> Do you have any way of monitoring the SQL that is being passed across
>>> from CF to MSSQL ( preferably something better than SQL profiler but that
>>> will do in a pinch).
>>>
>>> Once you verify the SQL that is being sent to MSQL from CF, analyze the
>>> SQL to see if the expected index is actually hit when the query is ran
>>> through the SQL engine.  That may identify a bottleneck or unexpected
>>> behavior right there.  If the expected index is not being "hit" then you can
>>> revise the SQL to include a SQL to force the index usage.
>>>
>>> Also, if you have a monitoring tool that is able to capture the SQL in
>>> real time when being passed see if there are concurrent SQL threads running
>>> that are causing deadlocks, especially "blocking" locks.  This would
>>> indicate multiple sql threading executing simultaneously and competing for
>>> the same SQL resources.  I would also begin to check if the tables that the
>>> SQL is 

RE: [ACFUG Discuss] Ideal memory & Configuration for CF Production server?

[Charlie Arehart]

Oh, alright Shawn. Fine! :-)

And Derrick, “we cool”. Was just clarifying, too. :-)

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of shawn gorrell
Sent: Tuesday, January 26, 2010 11:29 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Ideal memory & Configuration for CF Production 
server?

 

Come on Charlie, don't be so humble. You're one of the community stars, and 
have been for years. Revel in some kudos for a moment...

 

  _  

From: Charlie Arehart 
To: discussion@acfug.org
Sent: Tue, January 26, 2010 11:22:46 AM
Subject: RE: [ACFUG Discuss] Ideal memory & Configuration for CF Production 
server?

Well, I don’t know about the “super” part. :-) But I do what I can. I’m as 
grateful for so much I’ve learned from others here, including yourself. Happy 
to be a part of the community.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Ajas Mohammed
Sent: Tuesday, January 26, 2010 11:03 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Ideal memory & Configuration for CF Production 
server?

 

Thanks Charlie for confirming that setting.

Do you want to know where I learned that? The answer is : From Mr. Super 
Charlie Arehart. Thanks. :-)

 

 


- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink   
- 


- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink   
- 




-

To unsubscribe from this list, manage your profile @ 

http://www.acfug.org?fa=login.edituserform



For more info, see http://www.acfug.org/mailinglists

Archive @ http://www.mail-archive.com/discussion%40acfug.org/

List hosted by http://www.fusionlink.com

-

Re: [ACFUG Discuss] Issue --- Transaction (Process ID 136) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transact

[Ajas Mohammed]

Hi Greg,

I will try to answer to the best of my knowledge.

There are 407359 records in the table. There is only 1 record being updated.

Not sure if its full table is being locked or not.

Do you have the ability to analyze the actual statement to get an execution
plan?
Well, let me see if I understand this first. Do you mean to say, I can copy
the stored proc code in sql query analyzer and run the stored procedure code
and see the execution plan perhaps?


http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it represents
the wise choice of many alternatives.


On Tue, Jan 26, 2010 at 9:45 PM, Greg McTure  wrote:

> Hi Ajas:
>
> It may be helpful to see a section of your stored procedure code that is
> doing the updates.  Also, approximately how many records are in each of the
> tables being updated and approximately how many records are being updated?
> The SQL engine or optimizer may behave differently depending on the database
> brand (i.e. Oracle, MSSQL, Sybase, MySQL, etc); however, generally speaking
> if the predicate of your WHERE clause covers most of the records in your
> table then the optimizer will complete a full table scan even with the
> presence of the indices.
>
> I would also consider looking to see if the full table is being locked on
> the updates.  This should not be happening but it is just another angle to
> check out.  I would not think this would not be an issue since I know in
> Oracle even if you are updating an entire table only the current row will be
> locked during the update.
>
> I don't see anything off-hand with your update statements.  One can expect
> the best performance by updating the table with a single statement instead
> of multiple statements unless of'course you have so many records that your
> rollback segment becomes too small to support the number of records to be
> updated.
>
> Do you have the ability to analyze the actual statement to get an execution
> plan?
>
>
> On Tue, Jan 26, 2010 at 11:30 AM, Ajas Mohammed wrote:
>
>> Hi Greg,
>>
>> I found the stored proc which results in deadlock situation. It has lets
>> say about 10 updates like this
>>
>> update tbl set col3 = someval where col1 = @col1 and col2 = @col2
>>
>> update tbl set col4= someval where col1 = @col1 and col2 = @col2
>>
>> update tbl set col5 = someval where col1 = @col1 and col2 = @col2
>>  and so on for other cols 6-10.
>>
>> col1 and col2 are part of clustered index.
>>
>> I can share the code off the list.
>>
>> Thanks for your input. Makes lot of sense to get started with
>> troubleshooting.
>>
>> 
>> http://ajashadi.blogspot.com
>> We cannot become what we need to be, remaining what we are.
>> No matter what, find a way. Because thats what winners do.
>> You can't improve what you don't measure.
>> Quality is never an accident; it is always the result of high intention,
>> sincere effort, intelligent direction and skillful execution; it represents
>> the wise choice of many alternatives.
>>
>>
>>
>> On Fri, Oct 30, 2009 at 5:14 PM, Greg McTure  wrote:
>>
>>> Hi Ajas.
>>>
>>> Do you have any way of monitoring the SQL that is being passed across
>>> from CF to MSSQL ( preferably something better than SQL profiler but that
>>> will do in a pinch).
>>>
>>> Once you verify the SQL that is being sent to MSQL from CF, analyze the
>>> SQL to see if the expected index is actually hit when the query is ran
>>> through the SQL engine.  That may identify a bottleneck or unexpected
>>> behavior right there.  If the expected index is not being "hit" then you can
>>> revise the SQL to include a SQL to force the index usage.
>>>
>>> Also, if you have a monitoring tool that is able to capture the SQL in
>>> real time when being passed see if there are concurrent SQL threads running
>>> that are causing deadlocks, especially "blocking" locks.  This would
>>> indicate multiple sql threading executing simultaneously and competing for
>>> the same SQL resources.  I would also begin to check if the tables that the
>>> SQL is running against has "row level" or "table level" locking.  I have
>>> seen cases before when somehow the tables unknowingly became configured for
>>> "table" level locking and that caused the deadlock.
>>>
>>> Hopefully, these checks can get you started with trying to isolate the
>>> cause of the deadlock.
>>>
>>>
>>>
>>> On Fri, Oct 30, 2009 at 4:55 PM, Ajas Mohammed wrote:
>>>
 Hi,

 Just wondering if anyone faced the SQL Server deadlock error returned by
 ColdFusion. WE are using SQL Server 2000 and ColdFusion 7. The error
 returned is

 Error Executing Database Query. [Macromedia][SQLServer JDBC
 Driver][SQLServer]Transaction (Process ID 136) was deadlocked on lock |
 communic

Re: [ACFUG Discuss] Issue --- Transaction (Process ID 136) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transact

[Greg McTure]

Hi Ajas:

It may be helpful to see a section of your stored procedure code that is
doing the updates.  Also, approximately how many records are in each of the
tables being updated and approximately how many records are being updated?
The SQL engine or optimizer may behave differently depending on the database
brand (i.e. Oracle, MSSQL, Sybase, MySQL, etc); however, generally speaking
if the predicate of your WHERE clause covers most of the records in your
table then the optimizer will complete a full table scan even with the
presence of the indices.

I would also consider looking to see if the full table is being locked on
the updates.  This should not be happening but it is just another angle to
check out.  I would not think this would not be an issue since I know in
Oracle even if you are updating an entire table only the current row will be
locked during the update.

I don't see anything off-hand with your update statements.  One can expect
the best performance by updating the table with a single statement instead
of multiple statements unless of'course you have so many records that your
rollback segment becomes too small to support the number of records to be
updated.

Do you have the ability to analyze the actual statement to get an execution
plan?

On Tue, Jan 26, 2010 at 11:30 AM, Ajas Mohammed  wrote:

> Hi Greg,
>
> I found the stored proc which results in deadlock situation. It has lets
> say about 10 updates like this
>
> update tbl set col3 = someval where col1 = @col1 and col2 = @col2
>
> update tbl set col4= someval where col1 = @col1 and col2 = @col2
>
> update tbl set col5 = someval where col1 = @col1 and col2 = @col2
>  and so on for other cols 6-10.
>
> col1 and col2 are part of clustered index.
>
> I can share the code off the list.
>
> Thanks for your input. Makes lot of sense to get started with
> troubleshooting.
>
> 
> http://ajashadi.blogspot.com
> We cannot become what we need to be, remaining what we are.
> No matter what, find a way. Because thats what winners do.
> You can't improve what you don't measure.
> Quality is never an accident; it is always the result of high intention,
> sincere effort, intelligent direction and skillful execution; it represents
> the wise choice of many alternatives.
>
>
>
> On Fri, Oct 30, 2009 at 5:14 PM, Greg McTure  wrote:
>
>> Hi Ajas.
>>
>> Do you have any way of monitoring the SQL that is being passed across from
>> CF to MSSQL ( preferably something better than SQL profiler but that will do
>> in a pinch).
>>
>> Once you verify the SQL that is being sent to MSQL from CF, analyze the
>> SQL to see if the expected index is actually hit when the query is ran
>> through the SQL engine.  That may identify a bottleneck or unexpected
>> behavior right there.  If the expected index is not being "hit" then you can
>> revise the SQL to include a SQL to force the index usage.
>>
>> Also, if you have a monitoring tool that is able to capture the SQL in
>> real time when being passed see if there are concurrent SQL threads running
>> that are causing deadlocks, especially "blocking" locks.  This would
>> indicate multiple sql threading executing simultaneously and competing for
>> the same SQL resources.  I would also begin to check if the tables that the
>> SQL is running against has "row level" or "table level" locking.  I have
>> seen cases before when somehow the tables unknowingly became configured for
>> "table" level locking and that caused the deadlock.
>>
>> Hopefully, these checks can get you started with trying to isolate the
>> cause of the deadlock.
>>
>>
>>
>> On Fri, Oct 30, 2009 at 4:55 PM, Ajas Mohammed wrote:
>>
>>> Hi,
>>>
>>> Just wondering if anyone faced the SQL Server deadlock error returned by
>>> ColdFusion. WE are using SQL Server 2000 and ColdFusion 7. The error
>>> returned is
>>>
>>> Error Executing Database Query. [Macromedia][SQLServer JDBC
>>> Driver][SQLServer]Transaction (Process ID 136) was deadlocked on lock |
>>> communication buffer resources with another process and has been chosen as
>>> the deadlock victim. Rerun the transaction.
>>>
>>> Now, I do understand( from google search) that this could be because of
>>> bad indexing or long processing update insert select at same time etc. Can
>>> someone share their experience if any with this kind of issue. It would be
>>> nice to know how to tackle this issue because we are seeing this frequently
>>> in several applications.
>>>
>>> thanks,
>>>
>>> Ajas Mohammed.
>>>
>>>
>>
>

Re: [ACFUG Discuss] Issue --- Transaction (Process ID 136) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transact

[Ajas Mohammed]

Hi Greg,

I found the stored proc which results in deadlock situation. It has lets say
about 10 updates like this

update tbl set col3 = someval where col1 = @col1 and col2 = @col2

update tbl set col4= someval where col1 = @col1 and col2 = @col2

update tbl set col5 = someval where col1 = @col1 and col2 = @col2
 and so on for other cols 6-10.

col1 and col2 are part of clustered index.

I can share the code off the list.

Thanks for your input. Makes lot of sense to get started with
troubleshooting.


http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it represents
the wise choice of many alternatives.


On Fri, Oct 30, 2009 at 5:14 PM, Greg McTure  wrote:

> Hi Ajas.
>
> Do you have any way of monitoring the SQL that is being passed across from
> CF to MSSQL ( preferably something better than SQL profiler but that will do
> in a pinch).
>
> Once you verify the SQL that is being sent to MSQL from CF, analyze the SQL
> to see if the expected index is actually hit when the query is ran through
> the SQL engine.  That may identify a bottleneck or unexpected behavior right
> there.  If the expected index is not being "hit" then you can revise the SQL
> to include a SQL to force the index usage.
>
> Also, if you have a monitoring tool that is able to capture the SQL in real
> time when being passed see if there are concurrent SQL threads running that
> are causing deadlocks, especially "blocking" locks.  This would indicate
> multiple sql threading executing simultaneously and competing for the same
> SQL resources.  I would also begin to check if the tables that the SQL is
> running against has "row level" or "table level" locking.  I have seen cases
> before when somehow the tables unknowingly became configured for "table"
> level locking and that caused the deadlock.
>
> Hopefully, these checks can get you started with trying to isolate the
> cause of the deadlock.
>
>
>
> On Fri, Oct 30, 2009 at 4:55 PM, Ajas Mohammed  wrote:
>
>> Hi,
>>
>> Just wondering if anyone faced the SQL Server deadlock error returned by
>> ColdFusion. WE are using SQL Server 2000 and ColdFusion 7. The error
>> returned is
>>
>> Error Executing Database Query. [Macromedia][SQLServer JDBC
>> Driver][SQLServer]Transaction (Process ID 136) was deadlocked on lock |
>> communication buffer resources with another process and has been chosen as
>> the deadlock victim. Rerun the transaction.
>>
>> Now, I do understand( from google search) that this could be because of
>> bad indexing or long processing update insert select at same time etc. Can
>> someone share their experience if any with this kind of issue. It would be
>> nice to know how to tackle this issue because we are seeing this frequently
>> in several applications.
>>
>> thanks,
>>
>> Ajas Mohammed.
>>
>>
>

Re: [ACFUG Discuss] Ideal memory & Configuration for CF Production server?

[shawn gorrell]

Come on Charlie, don't be so humble. You're one of the community stars, and 
have been for years. Revel in some kudos for a moment...





From: Charlie Arehart 
To: discussion@acfug.org
Sent: Tue, January 26, 2010 11:22:46 AM
Subject: RE: [ACFUG Discuss] Ideal memory & Configuration for CF Production  
server?

 
Well, I don’t know about the “super” part. :-)
But I do what I can. I’m as grateful for so much I’ve learned from
others here, including yourself. Happy to be a part of the community.
 
/charlie
 
From:ad...@acfug.org
[mailto:ad...@acfug.org] On Behalf Of Ajas Mohammed
Sent: Tuesday, January 26, 2010 11:03 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Ideal memory & Configuration for CF
Production server?
 
Thanks Charlie for confirming
that setting.

Do you want to know where I learned that? The answer is : From Mr. Super
Charlie Arehart. Thanks. :-)

 
 
- 
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform 

For more info, see http://www.acfug.org/mailinglists 
Archive @ http://www.mail-archive.com/discussion%40acfug.org/ 
List hosted by FusionLink 
-


-

To unsubscribe from this list, manage your profile @ 

http://www.acfug.org?fa=login.edituserform



For more info, see http://www.acfug.org/mailinglists

Archive @ http://www.mail-archive.com/discussion%40acfug.org/

List hosted by http://www.fusionlink.com

-

RE: [ACFUG Discuss] Ideal memory & Configuration for CF Production server?

[Charlie Arehart]

Well, I don't know about the "super" part. :-) But I do what I can. I'm as
grateful for so much I've learned from others here, including yourself.
Happy to be a part of the community.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Ajas Mohammed
Sent: Tuesday, January 26, 2010 11:03 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Ideal memory & Configuration for CF Production
server?

 

Thanks Charlie for confirming that setting.

Do you want to know where I learned that? The answer is : From Mr. Super
Charlie Arehart. Thanks. :-)

 

 




-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-

Re: [ACFUG Discuss] Ideal memory & Configuration for CF Production server?

[Ajas Mohammed]

Thanks Charlie for confirming that setting.

Do you want to know where I learned that? The answer is : From Mr. Super
Charlie Arehart. Thanks. :-)


http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it represents
the wise choice of many alternatives.


On Tue, Jan 26, 2010 at 10:50 AM, Charlie Arehart wrote:

>  Ok, but to be clear I really was only discussing the technical aspect.
> I’m not sure what all the other observations brought to that part of the
> discussion. My bottom line point was not to argue against your use of client
> variables. I suggested a reason why one may choose to do it and yet treat
> them like session variables (with timeouts in hours/minutes rather than
> months/weeks), and that was if you can’t rely on sessions because they’re
> lost over restarts.  I just wanted to suggest that there was another
> approach (in the idea of J2EE sessions being persisted by the J2EE server,
> if offered as an option.) I should also have pointed out that multiple
> instances with replication (in CF Enterprise) would also afford the kind of
> protection of sessions over restarts, but many have a hard time getting that
> working acceptably, so it’s not the first thought I’d have for this problem
> I was suggesting. But if you have still other reasons to favor client vars
> over sessions, no worries. But yes, I do hope the info on sessions/bots may
> help. I’ll say again, though, that things in BD may be different. Can’t
> recall if they have the global client variables, lastvisit and hitcount.
>
>
>
> /charlie
>
>
>
> *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Derrick
> Peavy
> *Sent:* Monday, January 25, 2010 10:18 PM
>
> *To:* discussion@acfug.org
> *Subject:* Re: [ACFUG Discuss] Ideal memory & Configuration for CF
> Production server?
>
>
>
> Charlie:
>
>
>
> Good point about possibly treating client vars like session. I'd like to
> elaborate.
>
>
>
> I have 4 client vars in my app. That's all. Three are integers, and the
> fourth is a single char. Not sure that matters in any case.  Everything else
> is session aside from the static application vars that most people use.
>
>
>
> In general I think it's important to create apps that are specific to the
> business, the client, and the users who use them. Before you write that off
> as a "yeah, don't we all," what I want to emphasize in that, is the "user"
> part.
>
>
>
> With my main application, the traffic pattern of the user is such that they
> are not sticking around. I run a classifieds site and it's a very specific
> target. To compare, CraigsList gets about 20 pages views per user according
> to (cough) Alexa. Oodle gets 5-6. It's hard to compare - impossible - to
> these sites. But as a broad metric, having 2-3 pages per user visit is not
> bad. The bounce rate is low and basically, that's the nature of
> classifieds.
>
>
>
> That being said, if my average user is a touch and go user, and they are
> only looking at 2-3 pages, and their repeat frequency is going to be spread
> over several days possibly, then there is no value in retaining the client
> data. And when that client data is so sparse anyway (whole other topic),
> then it's even less important. On top of that, the client data that is used
> is non identifiable for the most part and is never required to be known by
> the user. So, when the session expires, it's no problem if the client data
> has been removed too.
>
>
>
> Again, this is less about CF or technical arguments than it is about the
> user pattern and the business needs. Additionally, while I do track usage
> internally (two systems), there is also Google Analytics which is going to
> track repeat users, etc., So again, the client data is of no value. If the
> user has been inactive for 6 hours (delete time), the client data is of no
> use no matter what.
>
>
>
> Now, the issue that prompted this "purging" on a regular basis is the issue
> of spiders and bots and crawlers (oh my). So, I noticed that you posted a
> link for that and I will be checking that out very carefully.
>
>
>
> Perhaps I can change my tactics.
>
> *
> _*
>
> *Derrick Peavy*
>
> derr...@derrickpeavy.com
>
> 404-786-5036
>
>
>
> *“Innovation distinguishes between a leader and a follower.” -Steve Jobs*
>
>
>
> *"A good deal that used to be a great deal, is not nearly as good as an
> awful deal that was once a horrible deal." - Dan Gilbert,
> http://bit.ly/8gUruX*
>
> *_*
>
>
>
>
>
> On Jan 25, 2010, at 4:01 PM, Charlie Arehart wrote:
>
>
>
>   Derrick, I’ll offer a couple of follow-ups to your points to help others
> with the discussion we’re now having.
>
> First, you mention using BD, and I’ll note that the problem that

RE: [ACFUG Discuss] Ideal memory & Configuration for CF Production server?

[Charlie Arehart]

Ok, but to be clear I really was only discussing the technical aspect. I'm
not sure what all the other observations brought to that part of the
discussion. My bottom line point was not to argue against your use of client
variables. I suggested a reason why one may choose to do it and yet treat
them like session variables (with timeouts in hours/minutes rather than
months/weeks), and that was if you can't rely on sessions because they're
lost over restarts.  I just wanted to suggest that there was another
approach (in the idea of J2EE sessions being persisted by the J2EE server,
if offered as an option.) I should also have pointed out that multiple
instances with replication (in CF Enterprise) would also afford the kind of
protection of sessions over restarts, but many have a hard time getting that
working acceptably, so it's not the first thought I'd have for this problem
I was suggesting. But if you have still other reasons to favor client vars
over sessions, no worries. But yes, I do hope the info on sessions/bots may
help. I'll say again, though, that things in BD may be different. Can't
recall if they have the global client variables, lastvisit and hitcount.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Derrick Peavy
Sent: Monday, January 25, 2010 10:18 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Ideal memory & Configuration for CF Production
server?

 

Charlie:

 

Good point about possibly treating client vars like session. I'd like to
elaborate.

 

I have 4 client vars in my app. That's all. Three are integers, and the
fourth is a single char. Not sure that matters in any case.  Everything else
is session aside from the static application vars that most people use.

 

In general I think it's important to create apps that are specific to the
business, the client, and the users who use them. Before you write that off
as a "yeah, don't we all," what I want to emphasize in that, is the "user"
part.

 

With my main application, the traffic pattern of the user is such that they
are not sticking around. I run a classifieds site and it's a very specific
target. To compare, CraigsList gets about 20 pages views per user according
to (cough) Alexa. Oodle gets 5-6. It's hard to compare - impossible - to
these sites. But as a broad metric, having 2-3 pages per user visit is not
bad. The bounce rate is low and basically, that's the nature of classifieds.


 

That being said, if my average user is a touch and go user, and they are
only looking at 2-3 pages, and their repeat frequency is going to be spread
over several days possibly, then there is no value in retaining the client
data. And when that client data is so sparse anyway (whole other topic),
then it's even less important. On top of that, the client data that is used
is non identifiable for the most part and is never required to be known by
the user. So, when the session expires, it's no problem if the client data
has been removed too.

 

Again, this is less about CF or technical arguments than it is about the
user pattern and the business needs. Additionally, while I do track usage
internally (two systems), there is also Google Analytics which is going to
track repeat users, etc., So again, the client data is of no value. If the
user has been inactive for 6 hours (delete time), the client data is of no
use no matter what. 

 

Now, the issue that prompted this "purging" on a regular basis is the issue
of spiders and bots and crawlers (oh my). So, I noticed that you posted a
link for that and I will be checking that out very carefully. 

 

Perhaps I can change my tactics. 


_

Derrick Peavy

derr...@derrickpeavy.com

404-786-5036

 

"Innovation distinguishes between a leader and a follower." -Steve Jobs

 

"A good deal that used to be a great deal, is not nearly as good as an awful
deal that was once a horrible deal." - Dan Gilbert, http://bit.ly/8gUruX

_





 

On Jan 25, 2010, at 4:01 PM, Charlie Arehart wrote:





Derrick, I'll offer a couple of follow-ups to your points to help others
with the discussion we're now having. 

First, you mention using BD, and I'll note that the problem that I bet was
hitting Ajas is not one that would happen on BD (the "global client variable
updates" that I discuss in the blog and recording I point to). So your
experience of the impact of client vars might be quite different from what
CFers would experience.

Second, you mention expiring sessions in 20-30 minutes. Whether on CF or BD
(or Railo), there is no connection between sessions and client variables.
The former are stored in memory and have timeouts in minutes or hours
typically, while client variables are stored in either a db, the registry,
or a cookie and have timeouts in days (the default being 90).

But your tool that purges those records that are more than even 6 hours old
suggests that you're using client variables like session variables. Maybe
you liked that the

RE: [ACFUG Discuss] Ideal memory & Configuration for CF Production server?

[Charlie Arehart]

Yep, Ajas, that's the one. It's a SERIOUS drain on most servers (for reasons
I elaborate on in the resources I linked to). So yes, if you do use the
client.lastvisit variable, you will want to seriously consider how valuable
it is and whether you might get value doing it otherwise.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Ajas Mohammed
Sent: Monday, January 25, 2010 4:40 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Ideal memory & Configuration for CF Production
server?

 

Hi,

Thanks Charlie for all your help and information. I really appreciate what
you do for the community. Like I said before, you are the first in my list.
I would get in touch with you right away when the time comes. :-)

As for the setting, I guess you were referring to the Disable global client
variable updates . In our case, we use lastvisit. So I dont think I can
disable it. Or atleast for now. :-)

Let me know if it is some other setting you were referring to. 

 

 




-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-