Re: Re: [ACFUG Discuss] Client? Session?
I think I explained it pretty well. There is some serious overhead to having to use WDDX to serialize your data and it doesn't even cover all of the data you would in reality want to serialize in a modern CFMX application. It has some serious overhead as database access typically involves a network connection and the impact to performance is great. And before that the application had to take the time to deserialize the data to an unpacked plain text format. Sure, hardware gets faster and faster all of the time, but this one is easy to avoid. So it isn't as flexible and robust for your average CF application. However, there are some cases where you really need it and I already pointed that out as well. When you absolutely can't lose client data you need it stored in a non volatile storage medium. The client scope fits the bill. Otherwise I see no reason to use the client scope. Did I mention client scope requires a database? Thats database connection every page for a user with a session identifier. That is typically at least two queries for every page request. In my mind that is a big deal. I try to be efficient and this is one place where you can just avoid bloat altogether and make a future proof design that can accommodate different requirements if you really need the client scope. As I said regardless of which you use you need to bury that choice with a good design as Dean said he has done. This means you can change it in the future if you need to without impacting anything but a tiny part of your application. Encapsulation is just an all around good design principle. So I made the claim "Don't use the client scope" because it fits for most people and I was then pretty careful to explain the situations you really need it. I then advocate that your software design should be flexible enough to use either in case your situation in your application ever changes. Something always changes. Plan for the future so you aren't caught with your guard down. Requirements and needs always change. JeremyOn 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote: Just out of curiosity, why would you say "Don't use the Client scope!"? Thanks, Allen -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy AllenSent: Saturday, September 30, 2006 12:30 AMTo: discussion@acfug.orgSubject: Re: Re: [ACFUG Discuss] Client? Session?Don't use the Client scope! There are only a few reasons to use Client scope and I would still think long and hard about it after having maintained an application that was almost purely Client scope for user state. I think you should avoid the client scope unless you have a real and hard requirement that you absolutely can't lose session data in the event of a server failure. I admit, it is kind of nice to still have all of your user sessions when you restart CF and that benefited our applications in some cases. However, I still don't think the benefits for Client scope are not worth it. Sticky sessions are OK in a load balanced situation. You may get some uneven clumping of clients in some cases, but in reality it turns out not to be a big deal. Playing with WDDX and the overheads involved in that and the pain of keeping track of the serialization state of your data just isn't worth it. You can't even serialize a CFC with WDDX, but they will happily live in the session scope. If you do use client scope make sure you abstract it with a good layer around it so that what scope you use is transparent to your application so that you can change it in the future without your application noticing. Look to the Facade design pattern for that.Jeremy On 9/27/06, Teddy Payne <[EMAIL PROTECTED]> wrote: Allen made a good point about WDDX. I tend to overlook CFWDDX. can dump your session into foo variable stored into the client scope.Your result in the DB would look similar to:foo=88107569CFID#=7101&CFTOKEN#=881075697101TESTAPP_7101_88107569# TeddyOn 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Just as an aside - you can still store complex structures in client variables but you'll have to wddx them into a string and then store them into the client variable. Also, if you do this and you have your client variables stored in the database, you'll want to make sure your datasource is enabled to retrieve BLOB's without the 64k limit. One other thing, if you're running on MX in JRUN configuration (not standalone), you can share the sessions between servers (if I remember right). J2EE has clustering built in and I believe it supports the equivalent of a session state server. Allen -Original
Re: [ACFUG Discuss] Client? Session?
You'd have to have one of the folks who still work at DI do it. Its their code, their technology. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] "Dissent is the purest form of patriotism." --Thomas Jefferson On Oct 2, 2006, at 11:20 AM, Teddy Payne wrote: That would be a great presentation for people with concerns for failover. Teddy On 10/2/06, Dean H. Saxe < [EMAIL PROTECTED]> wrote:At DI I wrote a session facade to allow runtime configuration of persistence to session, client or both scopes. This allowed flexibility in load balanced/failover environments while allowing the choice of best performance (session), performance + failover (session && client) or failover only (client). Worked like a charm, but it would require tweaking for your CFCs that need to be persisted. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] "Dissent is the purest form of patriotism." --Thomas Jefferson On Oct 2, 2006, at 10:31 AM, Teddy Payne wrote: > Not the CFC reading the client scope Steve, but more of serializing > the CFC into the client scope. > > The facade that I was referring to was a scope facade for the > session scope. I recently came across a facade pattern from Dave > Ross that to me shows serious promise for persistence if you want > to create less dependency on the session scope. > > http://www.d-ross.org/index.cfm?objectid=0DF6FA41-EB39- > B6C1-5D5D31A245991A2F > > The article is about Mach-II, but it can seperated and used > elsewhere. It is the second article in the three article series. > > Teddy > > On 10/2/06, Steven Ross <[EMAIL PROTECTED]> wrote: Yeah same here > and where is the info that says a CFC can't access the > client scope? > > On 10/2/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > > I am curious as well. The example of not storing being being > able to > > effectively store a value or service object is a limitation to be > sure, but > > even then that can be worked around with a facade. > > > > Teddy > > > > > > On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > Just out of curiosity, why would you say "Don't use the Client > scope!"? > > > > > > Thanks, > > > > > > Allen > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] Behalf Of > Jeremy Allen > > > Sent: Saturday, September 30, 2006 12:30 AM > > > To: discussion@acfug.org > > > Subject: Re: Re: [ACFUG Discuss] Client? Session? > > > > > > Don't use the Client scope! There are only a few reasons to use > Client > > scope and I would still think long and hard about it after having > maintained > > an application that was almost purely Client scope for user > state. I think > > you should avoid the client scope unless you have a real and hard > > requirement that you absolutely can't lose session data in the > event of a > > server failure. I admit, it is kind of nice to still have all of > your user > > sessions when you restart CF and that benefited our applications > in some > > cases. However, I still don't think the benefits for Client scope > are not > > worth it. Sticky sessions are OK in a load balanced situation. > You may get > > some uneven clumping of clients in some cases, but in reality it > turns out > > not to be a big deal. Playing with WDDX and the overheads > involved in that > > and the pain of keeping track of the serialization state of your > data just > > isn't worth it. > > > > > > You can't even serialize a CFC with WDDX, but they will happily > live in > > the session scope. If you do use client scope make sure you > abstract it with > > a good layer around it so that what scope you use is transparent > to your > > application so that you can change it in the future without your > application > > noticing. Look to the Facade design pattern for that. > > > > > > Jeremy > > > > > > > > > On 9/27/06, Teddy Payne < [EMAIL PROTECTED]> wrote: > > > > Allen made a good point about WDDX. I tend to overlook CFWDDX. > > > > > > > > > > > > > > > > > > > > can dump your session into foo > variable > > stored into the client scope. > > > > > > > > Your result in the DB would look similar to: > > > > foo= > name#='cftoken'>88107569 > name#='urltoken'>CFID#=7101&CFTOKEN#=88107569 string> &g
Re: Re: Re: Re: [ACFUG Discuss] Client? Session?
Gotcha, thanks On 10/2/06, Teddy Payne <[EMAIL PROTECTED]> wrote: Not the CFC reading the client scope Steve, but more of serializing the CFC into the client scope. The facade that I was referring to was a scope facade for the session scope. I recently came across a facade pattern from Dave Ross that to me shows serious promise for persistence if you want to create less dependency on the session scope. http://www.d-ross.org/index.cfm?objectid=0DF6FA41-EB39-B6C1-5D5D31A245991A2F The article is about Mach-II, but it can seperated and used elsewhere. It is the second article in the three article series. Teddy On 10/2/06, Steven Ross <[EMAIL PROTECTED]> wrote: > > Yeah same here and where is the info that says a CFC can't access the > client scope? > > On 10/2/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > > I am curious as well. The example of not storing being being able to > > effectively store a value or service object is a limitation to be sure, but > > even then that can be worked around with a facade. > > > > Teddy > > > > > > On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > Just out of curiosity, why would you say "Don't use the Client scope!"? > > > > > > Thanks, > > > > > > Allen > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] Behalf Of Jeremy Allen > > > Sent: Saturday, September 30, 2006 12:30 AM > > > To: discussion@acfug.org > > > Subject: Re: Re: [ACFUG Discuss] Client? Session? > > > > > > Don't use the Client scope! There are only a few reasons to use Client > > scope and I would still think long and hard about it after having maintained > > an application that was almost purely Client scope for user state. I think > > you should avoid the client scope unless you have a real and hard > > requirement that you absolutely can't lose session data in the event of a > > server failure. I admit, it is kind of nice to still have all of your user > > sessions when you restart CF and that benefited our applications in some > > cases. However, I still don't think the benefits for Client scope are not > > worth it. Sticky sessions are OK in a load balanced situation. You may get > > some uneven clumping of clients in some cases, but in reality it turns out > > not to be a big deal. Playing with WDDX and the overheads involved in that > > and the pain of keeping track of the serialization state of your data just > > isn't worth it. > > > > > > You can't even serialize a CFC with WDDX, but they will happily live in > > the session scope. If you do use client scope make sure you abstract it with > > a good layer around it so that what scope you use is transparent to your > > application so that you can change it in the future without your application > > noticing. Look to the Facade design pattern for that. > > > > > > Jeremy > > > > > > > > > On 9/27/06, Teddy Payne < [EMAIL PROTECTED]> wrote: > > > > Allen made a good point about WDDX. I tend to overlook CFWDDX. > > > > > > > > > > > > > > > > > > > > can dump your session into foo variable > > stored into the client scope. > > > > > > > > Your result in the DB would look similar to: > > > > foo= > name#='cftoken'>88107569 > name#='urltoken'>CFID#=7101&CFTOKEN#=88107569 > name#='cfid'>7101 > name#='sessionid'>TESTAPP_7101_88107569# > > > > > > > > Teddy > > > > > > > > On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > Just as an aside - you can still store complex structures in client > > variables but you'll have to wddx them into a string and then store them > > into the client variable. Also, if you do this and you have your client > > variables stored in the database, you'll want to make sure your datasource > > is enabled to retrieve BLOB's without the 64k limit. > > > > > > > > > > One other thing, if you're running on MX in JRUN configuration (not > > standalone), you can share the sessions between servers (if I remember > > right). J2EE has clustering built in and I believe it supports the > > equivalent of a session state server. > > > > > > > > > > Allen &
Re: [ACFUG Discuss] Client? Session?
That would be a great presentation for people with concerns for failover.TeddyOn 10/2/06, Dean H. Saxe < [EMAIL PROTECTED]> wrote:At DI I wrote a session facade to allow runtime configuration of persistence to session, client or both scopes. This allowedflexibility in load balanced/failover environments while allowing thechoice of best performance (session), performance + failover (session&& client) or failover only (client). Worked like a charm, but it would require tweaking for your CFCs that need to be persisted.-dhsDean H. Saxe, CISSP, CEH[EMAIL PROTECTED]"Dissent is the purest form of patriotism." --Thomas JeffersonOn Oct 2, 2006, at 10:31 AM, Teddy Payne wrote:> Not the CFC reading the client scope Steve, but more of serializing> the CFC into the client scope.>> The facade that I was referring to was a scope facade for the > session scope. I recently came across a facade pattern from Dave> Ross that to me shows serious promise for persistence if you want> to create less dependency on the session scope.>> http://www.d-ross.org/index.cfm?objectid=0DF6FA41-EB39-> B6C1-5D5D31A245991A2F>> The article is about Mach-II, but it can seperated and used > elsewhere. It is the second article in the three article series.>> Teddy>> On 10/2/06, Steven Ross <[EMAIL PROTECTED]> wrote: Yeah same here > and where is the info that says a CFC can't access the> client scope?>> On 10/2/06, Teddy Payne <[EMAIL PROTECTED]> wrote:> > I am curious as well. The example of not storing being being > able to> > effectively store a value or service object is a limitation to be> sure, but> > even then that can be worked around with a facade.> >> > Teddy> > > >> > On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:> > >> > >> > > Just out of curiosity, why would you say "Don't use the Client > scope!"?> > >> > > Thanks,> > >> > > Allen> > >> > >> > > -Original Message-> > > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]]On Behalf Of> Jeremy Allen> > > Sent: Saturday, September 30, 2006 12:30 AM> > > To: discussion@acfug.org> > > Subject: Re: Re: [ACFUG Discuss] Client? Session?> > >> > > Don't use the Client scope! There are only a few reasons to use> Client> > scope and I would still think long and hard about it after having > maintained> > an application that was almost purely Client scope for user> state. I think> > you should avoid the client scope unless you have a real and hard> > requirement that you absolutely can't lose session data in the > event of a> > server failure. I admit, it is kind of nice to still have all of> your user> > sessions when you restart CF and that benefited our applications> in some> > cases. However, I still don't think the benefits for Client scope > are not> > worth it. Sticky sessions are OK in a load balanced situation.> You may get> > some uneven clumping of clients in some cases, but in reality it> turns out> > not to be a big deal. Playing with WDDX and the overheads > involved in that> > and the pain of keeping track of the serialization state of your> data just> > isn't worth it.> > >> > > You can't even serialize a CFC with WDDX, but they will happily > live in> > the session scope. If you do use client scope make sure you> abstract it with> > a good layer around it so that what scope you use is transparent> to your> > application so that you can change it in the future without your > application> > noticing. Look to the Facade design pattern for that.> > >> > > Jeremy> > >> > >> > > On 9/27/06, Teddy Payne < [EMAIL PROTECTED]> wrote:> > > > Allen made a good point about WDDX. I tend to overlook CFWDDX.> > > >> > > >> > > > > > > >> > > > can dump your session into foo> variable> > stored into the client scope.> > > > > > > > Your result in the DB would look similar to:> > > > foo=> > name#='cftoken'>88107569> > name#='urltoken'>CFID#=7101&CFTOKEN#=88107569> string>> > name#='cfid'>7101> > name#='sessionid'>TESTAPP_7101_88107569> struct># > > > >> > > > Teddy> > > >> > > > On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote:> > > >> > > > >> > > > >> > > > > Just as an
Re: [ACFUG Discuss] Client? Session?
At DI I wrote a session facade to allow runtime configuration of persistence to session, client or both scopes. This allowed flexibility in load balanced/failover environments while allowing the choice of best performance (session), performance + failover (session && client) or failover only (client). Worked like a charm, but it would require tweaking for your CFCs that need to be persisted. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] "Dissent is the purest form of patriotism." --Thomas Jefferson On Oct 2, 2006, at 10:31 AM, Teddy Payne wrote: Not the CFC reading the client scope Steve, but more of serializing the CFC into the client scope. The facade that I was referring to was a scope facade for the session scope. I recently came across a facade pattern from Dave Ross that to me shows serious promise for persistence if you want to create less dependency on the session scope. http://www.d-ross.org/index.cfm?objectid=0DF6FA41-EB39- B6C1-5D5D31A245991A2F The article is about Mach-II, but it can seperated and used elsewhere. It is the second article in the three article series. Teddy On 10/2/06, Steven Ross <[EMAIL PROTECTED]> wrote: Yeah same here and where is the info that says a CFC can't access the client scope? On 10/2/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > I am curious as well. The example of not storing being being able to > effectively store a value or service object is a limitation to be sure, but > even then that can be worked around with a facade. > > Teddy > > > On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > Just out of curiosity, why would you say "Don't use the Client scope!"? > > > > Thanks, > > > > Allen > > > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] Behalf Of Jeremy Allen > > Sent: Saturday, September 30, 2006 12:30 AM > > To: discussion@acfug.org > > Subject: Re: Re: [ACFUG Discuss] Client? Session? > > > > Don't use the Client scope! There are only a few reasons to use Client > scope and I would still think long and hard about it after having maintained > an application that was almost purely Client scope for user state. I think > you should avoid the client scope unless you have a real and hard > requirement that you absolutely can't lose session data in the event of a > server failure. I admit, it is kind of nice to still have all of your user > sessions when you restart CF and that benefited our applications in some > cases. However, I still don't think the benefits for Client scope are not > worth it. Sticky sessions are OK in a load balanced situation. You may get > some uneven clumping of clients in some cases, but in reality it turns out > not to be a big deal. Playing with WDDX and the overheads involved in that > and the pain of keeping track of the serialization state of your data just > isn't worth it. > > > > You can't even serialize a CFC with WDDX, but they will happily live in > the session scope. If you do use client scope make sure you abstract it with > a good layer around it so that what scope you use is transparent to your > application so that you can change it in the future without your application > noticing. Look to the Facade design pattern for that. > > > > Jeremy > > > > > > On 9/27/06, Teddy Payne < [EMAIL PROTECTED]> wrote: > > > Allen made a good point about WDDX. I tend to overlook CFWDDX. > > > > > > > > > > > > > > > can dump your session into foo variable > stored into the client scope. > > > > > > Your result in the DB would look similar to: > > > foo= name#='cftoken'>88107569> name#='urltoken'>CFID#=7101&CFTOKEN#=88107569string> > name#='cfid'>7101> name#='sessionid'>TESTAPP_7101_88107569struct># > > > > > > Teddy > > > > > > On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > Just as an aside - you can still store complex structures in client > variables but you'll have to wddx them into a string and then store them > into the client variable. Also, if you do this and you have your client > variables stored in the database, you'll want to make sure your datasource > is enabled to retrieve BLOB's without the 64k limit. > > > > > > > > One other thing, if you're running on MX in JRUN configuration (not > standalone), you can share the session
Re: Re: Re: [ACFUG Discuss] Client? Session?
Not the CFC reading the client scope Steve, but more of serializing the CFC into the client scope.The facade that I was referring to was a scope facade for the session scope. I recently came across a facade pattern from Dave Ross that to me shows serious promise for persistence if you want to create less dependency on the session scope. http://www.d-ross.org/index.cfm?objectid=0DF6FA41-EB39-B6C1-5D5D31A245991A2FThe article is about Mach-II, but it can seperated and used elsewhere. It is the second article in the three article series. TeddyOn 10/2/06, Steven Ross <[EMAIL PROTECTED]> wrote: Yeah same here and where is the info that says a CFC can't access theclient scope?On 10/2/06, Teddy Payne <[EMAIL PROTECTED]> wrote:> I am curious as well. The example of not storing being being able to > effectively store a value or service object is a limitation to be sure, but> even then that can be worked around with a facade.>> Teddy>>> On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:> >> >> > Just out of curiosity, why would you say "Don't use the Client scope!"? > >> > Thanks,> >> > Allen> >> >> > -Original Message-> > From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]]On Behalf Of Jeremy Allen> > Sent: Saturday, September 30, 2006 12:30 AM> > To: discussion@acfug.org> > Subject: Re: Re: [ACFUG Discuss] Client? Session? > >> > Don't use the Client scope! There are only a few reasons to use Client> scope and I would still think long and hard about it after having maintained> an application that was almost purely Client scope for user state. I think > you should avoid the client scope unless you have a real and hard> requirement that you absolutely can't lose session data in the event of a> server failure. I admit, it is kind of nice to still have all of your user > sessions when you restart CF and that benefited our applications in some> cases. However, I still don't think the benefits for Client scope are not> worth it. Sticky sessions are OK in a load balanced situation. You may get > some uneven clumping of clients in some cases, but in reality it turns out> not to be a big deal. Playing with WDDX and the overheads involved in that> and the pain of keeping track of the serialization state of your data just > isn't worth it.> >> > You can't even serialize a CFC with WDDX, but they will happily live in> the session scope. If you do use client scope make sure you abstract it with> a good layer around it so that what scope you use is transparent to your > application so that you can change it in the future without your application> noticing. Look to the Facade design pattern for that.> >> > Jeremy> >> >> > On 9/27/06, Teddy Payne < [EMAIL PROTECTED]> wrote:> > > Allen made a good point about WDDX. I tend to overlook CFWDDX.> > >> > >> > > > > >> > > can dump your session into foo variable> stored into the client scope.> > >> > > Your result in the DB would look similar to: > > > foo=> name#='cftoken'>88107569> name#='urltoken'>CFID#=7101&CFTOKEN#=88107569> name#='cfid'>7101> name#='sessionid'>TESTAPP_7101_88107569# > > >> > > Teddy> > >> > > On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >> > > > Just as an aside - you can still store complex structures in client> variables but you'll have to wddx them into a string and then store them > into the client variable. Also, if you do this and you have your client> variables stored in the database, you'll want to make sure your datasource> is enabled to retrieve BLOB's without the 64k limit. > > > >> > > > One other thing, if you're running on MX in JRUN configuration (not> standalone), you can share the sessions between servers (if I remember> right). J2EE has clustering built in and I believe it supports the > equivalent of a session state server.> > > >> > > > Allen> > > >> > > >> > > > -Original Message-> > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of> [EMAIL PROTECTED] > > > > Sent: Wednesday, September 27, 2006 9:22 AM> > > > To: discussion@acfug.org> > > > Subject: Re: Re: [ACFUG Discuss] Client? Session? > > > >> > > >> > > > In general it seems to me that the rule is that once a user is on a> server, they are on the same server. Define complex data. I pot
Re: Re: Re: [ACFUG Discuss] Client? Session?
Yeah same here and where is the info that says a CFC can't access the client scope? On 10/2/06, Teddy Payne <[EMAIL PROTECTED]> wrote: I am curious as well. The example of not storing being being able to effectively store a value or service object is a limitation to be sure, but even then that can be worked around with a facade. Teddy On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > Just out of curiosity, why would you say "Don't use the Client scope!"? > > Thanks, > > Allen > > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jeremy Allen > Sent: Saturday, September 30, 2006 12:30 AM > To: discussion@acfug.org > Subject: Re: Re: [ACFUG Discuss] Client? Session? > > Don't use the Client scope! There are only a few reasons to use Client scope and I would still think long and hard about it after having maintained an application that was almost purely Client scope for user state. I think you should avoid the client scope unless you have a real and hard requirement that you absolutely can't lose session data in the event of a server failure. I admit, it is kind of nice to still have all of your user sessions when you restart CF and that benefited our applications in some cases. However, I still don't think the benefits for Client scope are not worth it. Sticky sessions are OK in a load balanced situation. You may get some uneven clumping of clients in some cases, but in reality it turns out not to be a big deal. Playing with WDDX and the overheads involved in that and the pain of keeping track of the serialization state of your data just isn't worth it. > > You can't even serialize a CFC with WDDX, but they will happily live in the session scope. If you do use client scope make sure you abstract it with a good layer around it so that what scope you use is transparent to your application so that you can change it in the future without your application noticing. Look to the Facade design pattern for that. > > Jeremy > > > On 9/27/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > > Allen made a good point about WDDX. I tend to overlook CFWDDX. > > > > > > > > > > can dump your session into foo variable stored into the client scope. > > > > Your result in the DB would look similar to: > > foo=88107569CFID#=7101&CFTOKEN#=881075697101TESTAPP_7101_88107569# > > > > Teddy > > > > On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Just as an aside - you can still store complex structures in client variables but you'll have to wddx them into a string and then store them into the client variable. Also, if you do this and you have your client variables stored in the database, you'll want to make sure your datasource is enabled to retrieve BLOB's without the 64k limit. > > > > > > One other thing, if you're running on MX in JRUN configuration (not standalone), you can share the sessions between servers (if I remember right). J2EE has clustering built in and I believe it supports the equivalent of a session state server. > > > > > > Allen > > > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] > > > Sent: Wednesday, September 27, 2006 9:22 AM > > > To: discussion@acfug.org > > > Subject: Re: Re: [ACFUG Discuss] Client? Session? > > > > > > > > > In general it seems to me that the rule is that once a user is on a server, they are on the same server. Define complex data. I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet. We don't officially have any code written. > > > > > > mcg > > > > > > > > > > > > > > > > > > Steven Ross <[EMAIL PROTECTED]> > > > Sent by: [EMAIL PROTECTED] > > > > > > 09/26/2006 08:04 PM > > > > > > Please respond to > > > discussion@acfug.org > > > > > > > > > [EMAIL PROTECTED] > > > > > > cc > > > > > > > > > SubjectRe: Re: [ACFUG Discuss] Client? Session? > > > > > > > > > > > > > > > > > > > > > > > > Yeah it depends on how you want your requests routed... it is my > > > understanding that if you want the machines to round robin each > > > request then you need to do client variables, if you don't care and > > > you just want users to stay on one server then
Re: Re: [ACFUG Discuss] Client? Session?
I am curious as well. The example of not storing being being able to effectively store a value or service object is a limitation to be sure, but even then that can be worked around with a facade.Teddy
On 10/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Just
out of curiosity, why would you say "Don't use the Client
scope!"?
Thanks,
Allen
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jeremy AllenSent:
Saturday, September 30, 2006 12:30 AMTo:
discussion@acfug.orgSubject: Re: Re: [ACFUG Discuss] Client?
Session?Don't use the Client scope! There are only a few
reasons to use Client scope and I would still think long and hard about it
after having maintained an application that was almost purely Client scope for
user state. I think you should avoid the client scope unless you have a
real and hard requirement that you absolutely can't lose session data in the
event of a server failure. I admit, it is kind of nice to still have all of
your user sessions when you restart CF and that benefited our applications in
some cases. However, I still don't think the benefits for Client scope are not
worth it. Sticky sessions are OK in a load balanced situation. You may get
some uneven clumping of clients in some cases, but in reality it turns out not
to be a big deal. Playing with WDDX and the overheads involved in that and the
pain of keeping track of the serialization state of your data just isn't worth
it. You can't even serialize a CFC with WDDX, but they will happily
live in the session scope. If you do use client scope make sure you abstract
it with a good layer around it so that what scope you use is transparent to
your application so that you can change it in the future without your
application noticing. Look to the Facade design pattern for
that.Jeremy
On 9/27/06, Teddy
Payne <[EMAIL PROTECTED]>
wrote:
Allen
made a good point about WDDX. I tend to overlook CFWDDX.
can dump your session into foo variable stored into
the client scope.Your result in the DB would look similar
to:foo=88107569CFID#=7101&CFTOKEN#=881075697101TESTAPP_7101_88107569#
TeddyOn 9/27/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
wrote:
Just as an aside - you
can still store complex structures in client variables but you'll have to
wddx them into a string and then store them into the client
variable. Also, if you do this and you have your client variables
stored in the database, you'll want to make sure your datasource is
enabled to retrieve BLOB's without the 64k limit.
One other thing, if
you're running on MX in JRUN configuration (not standalone), you can share
the sessions between servers (if I remember right). J2EE has
clustering built in and I believe it supports the equivalent of a session
state server.
Allen
-Original
Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of [EMAIL PROTECTED]Sent:
Wednesday, September 27, 2006 9:22 AMTo: discussion@acfug.orgSubject: Re: Re: [ACFUG
Discuss] Client? Session?In general it seems to me that the rule is that once a user is on
a server, they are on the same server. Define complex data.
I potentially see structures and possibly an occasional object in
the shared scope, but honestly I don't know yet. We don't
officially have any code written. mcg
Steven Ross <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
09/26/2006 08:04 PM
Please
respond todiscussion@acfug.org
To
discussion@acfug.org
cc
Subject
Re: Re: [ACFUG Discuss]
Client? Session?
Yeah it depends on how you want your requests routed... it is
myunderstanding that if you want the machines to round robin
eachrequest then you need to do client variables, if you don't care
andyou just want users to stay on one server then you can use
sessions.On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote:> Are you
looking to store complex data in your shared scope? If so, you
need> some sort of sticky session solution. If you are
looki
RE: Re: [ACFUG Discuss] Client? Session?
Just
out of curiosity, why would you say "Don't use the Client
scope!"?
Thanks,
Allen
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Jeremy AllenSent:
Saturday, September 30, 2006 12:30 AMTo:
discussion@acfug.orgSubject: Re: Re: [ACFUG Discuss] Client?
Session?Don't use the Client scope! There are only a few
reasons to use Client scope and I would still think long and hard about it
after having maintained an application that was almost purely Client scope for
user state. I think you should avoid the client scope unless you have a
real and hard requirement that you absolutely can't lose session data in the
event of a server failure. I admit, it is kind of nice to still have all of
your user sessions when you restart CF and that benefited our applications in
some cases. However, I still don't think the benefits for Client scope are not
worth it. Sticky sessions are OK in a load balanced situation. You may get
some uneven clumping of clients in some cases, but in reality it turns out not
to be a big deal. Playing with WDDX and the overheads involved in that and the
pain of keeping track of the serialization state of your data just isn't worth
it. You can't even serialize a CFC with WDDX, but they will happily
live in the session scope. If you do use client scope make sure you abstract
it with a good layer around it so that what scope you use is transparent to
your application so that you can change it in the future without your
application noticing. Look to the Facade design pattern for
that.Jeremy
On 9/27/06, Teddy
Payne <[EMAIL PROTECTED]>
wrote:
Allen
made a good point about WDDX. I tend to overlook CFWDDX.
can dump your session into foo variable stored into
the client scope.Your result in the DB would look similar
to:foo=88107569CFID#=7101&CFTOKEN#=881075697101TESTAPP_7101_88107569#
TeddyOn 9/27/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
wrote:
Just as an aside - you
can still store complex structures in client variables but you'll have to
wddx them into a string and then store them into the client
variable. Also, if you do this and you have your client variables
stored in the database, you'll want to make sure your datasource is
enabled to retrieve BLOB's without the 64k limit.
One other thing, if
you're running on MX in JRUN configuration (not standalone), you can share
the sessions between servers (if I remember right). J2EE has
clustering built in and I believe it supports the equivalent of a session
state server.
Allen
-Original
Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of [EMAIL PROTECTED]Sent:
Wednesday, September 27, 2006 9:22 AMTo: discussion@acfug.orgSubject: Re: Re: [ACFUG
Discuss] Client? Session?In general it seems to me that the rule is that once a user is on
a server, they are on the same server. Define complex data.
I potentially see structures and possibly an occasional object in
the shared scope, but honestly I don't know yet. We don't
officially have any code written. mcg
Steven Ross <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED]
09/26/2006 08:04 PM
Please
respond todiscussion@acfug.org
To
discussion@acfug.org
cc
Subject
Re: Re: [ACFUG Discuss]
Client? Session?
Yeah it depends on how you want your requests routed... it is
myunderstanding that if you want the machines to round robin
eachrequest then you need to do client variables, if you don't care
andyou just want users to stay on one server then you can use
sessions.On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote:> Are you
looking to store complex data in your shared scope? If so, you
need> some sort of sticky session solution. If you are
looking to store simple> data, using the datasource option of
client variable storeage would make it> easier to switch over
between servers.>> Teddy>>> On
9/26/06, [EMAIL PROTECTED] <> [EMAIL PROTECTED]>
wrote:>
Re: Re: [ACFUG Discuss] Client? Session?
Don't use the Client scope! There are only a few reasons to use Client
scope and I would still think long and hard about it after having
maintained an application that was almost purely Client scope for user
state. I think you should avoid the client scope unless you have
a real and hard requirement that you absolutely can't lose session data
in the event of a server failure. I admit, it is kind of nice to still
have all of your user sessions when you restart CF and that benefited
our applications in some cases. However, I still don't think the
benefits for Client scope are not worth it. Sticky sessions are OK in a
load balanced situation. You may get some uneven clumping of clients in
some cases, but in reality it turns out not to be a big deal. Playing
with WDDX and the overheads involved in that and the pain of keeping
track of the serialization state of your data just isn't worth it.
You can't even serialize a CFC with WDDX, but they will happily live in
the session scope. If you do use client scope make sure you abstract it
with a good layer around it so that what scope you use is transparent
to your application so that you can change it in the future without
your application noticing. Look to the Facade design pattern for that.
JeremyOn 9/27/06, Teddy Payne <[EMAIL PROTECTED]> wrote:
Allen made a good point about WDDX. I tend to overlook CFWDDX.
can dump your session into foo variable stored into the client scope.Your result in the DB would look similar to:foo=88107569CFID#=7101&CFTOKEN#=881075697101TESTAPP_7101_88107569#
TeddyOn 9/27/06,
[EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Just
as an aside - you can still store complex structures in client variables but
you'll have to wddx them into a string and then store them into the client
variable. Also, if you do this and you have your client variables stored
in the database, you'll want to make sure your datasource is enabled to retrieve
BLOB's without the 64k limit.
One
other thing, if you're running on MX in JRUN configuration (not standalone), you
can share the sessions between servers (if I remember right). J2EE has
clustering built in and I believe it supports the equivalent of a session state
server.
Allen
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]Sent: Wednesday, September
27, 2006 9:22 AMTo: discussion@acfug.orgSubject: Re: Re:
[ACFUG Discuss] Client? Session?In general it seems to me that the rule is that once a user is on a
server, they are on the same server. Define complex data. I
potentially see structures and possibly an occasional object in the shared
scope, but honestly I don't know yet. We don't officially have any code
written. mcg
Steven Ross
<[EMAIL PROTECTED]> Sent by:
[EMAIL PROTECTED]
09/26/2006 08:04 PM
Please respond
todiscussion@acfug.org
To
discussion@acfug.org
cc
Subject
Re: Re: [ACFUG Discuss] Client?
Session?
Yeah it depends on how you want your requests routed... it is
myunderstanding that if you want the machines to round robin
eachrequest then you need to do client variables, if you don't care
andyou just want users to stay on one server then you can use
sessions.On 9/26/06, Teddy Payne <[EMAIL PROTECTED]>
wrote:> Are you looking to store complex data in your shared scope?
If so, you need> some sort of sticky session solution. If
you are looking to store simple> data, using the datasource option of
client variable storeage would make it> easier to switch over between
servers.>> Teddy>>> On 9/26/06,
[EMAIL PROTECTED] <>
[EMAIL PROTECTED]> wrote:> >> > I'm
a little confused as to what scope of variables to use in our>
situation. We have a primary server and a 'backup' server in case
the> primary fails. Now that is the current situation.
Eventually the backup> will be replaced with a better machine and
the load will be balanced a> little more evenly. Currently the
balancing is done via Resonate software> (and no one seems to like it).
As far as 100% failover, I really don't see> that as a necessity,
these aren't banking applications. Also these servers> don't talk
to each other that I know of.> >> > TIA>
>> > Mary-Catherine> >>
-> > To
unsubscribe from this list, manage
Re: Re: [ACFUG Discuss] Client? Session?
Yep, just making sure your definition matched my definition. :) mcg Teddy Payne <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/27/2006 09:47 AM Please respond to discussion@acfug.org To discussion@acfug.org cc Subject Re: Re: [ACFUG Discuss] Client? Session? Complex data would be arrays, structures, queries, objects ..etc. Client variables can store simple data like strings, integers, boolean ...etc. I hope that makes sense, Teddy On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote: In general it seems to me that the rule is that once a user is on a server, they are on the same server. Define complex data. I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet. We don't officially have any code written. mcg Steven Ross <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2006 08:04 PM Please respond to discussion@acfug.org To discussion@acfug.org cc Subject Re: Re: [ACFUG Discuss] Client? Session? Yeah it depends on how you want your requests routed... it is my understanding that if you want the machines to round robin each request then you need to do client variables, if you don't care and you just want users to stay on one server then you can use sessions. On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > Are you looking to store complex data in your shared scope? If so, you need > some sort of sticky session solution. If you are looking to store simple > data, using the datasource option of client variable storeage would make it > easier to switch over between servers. > > Teddy > > > On 9/26/06, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> wrote: > > > > I'm a little confused as to what scope of variables to use in our > situation. We have a primary server and a 'backup' server in case the > primary fails. Now that is the current situation. Eventually the backup > will be replaced with a better machine and the load will be balanced a > little more evenly. Currently the balancing is done via Resonate software > (and no one seems to like it). As far as 100% failover, I really don't see > that as a necessity, these aren't banking applications. Also these servers > don't talk to each other that I know of. > > > > TIA > > > > Mary-Catherine > > > - > > 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 > > > - > > > > -- > > > Blog: http://cfpayne.wordpress.com/ > Atlanta CFUG: http://www.acfug.org > > - > 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 > - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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 - - 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 - -- Blog: http://cfpayne.wordpress.com/ Atlanta CFUG: http://www.acfug.org - 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 -
Re: Re: [ACFUG Discuss] Client? Session?
Allen made a good point about WDDX. I tend to overlook CFWDDX.
can dump your session into foo variable stored into the client scope.Your result in the DB would look similar to:foo=88107569CFID#=7101&CFTOKEN#=881075697101TESTAPP_7101_88107569#
TeddyOn 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Just
as an aside - you can still store complex structures in client variables but
you'll have to wddx them into a string and then store them into the client
variable. Also, if you do this and you have your client variables stored
in the database, you'll want to make sure your datasource is enabled to retrieve
BLOB's without the 64k limit.
One
other thing, if you're running on MX in JRUN configuration (not standalone), you
can share the sessions between servers (if I remember right). J2EE has
clustering built in and I believe it supports the equivalent of a session state
server.
Allen
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]Sent: Wednesday, September
27, 2006 9:22 AMTo: discussion@acfug.orgSubject: Re: Re:
[ACFUG Discuss] Client? Session?In general it seems to me that the rule is that once a user is on a
server, they are on the same server. Define complex data. I
potentially see structures and possibly an occasional object in the shared
scope, but honestly I don't know yet. We don't officially have any code
written. mcg
Steven Ross
<[EMAIL PROTECTED]> Sent by:
[EMAIL PROTECTED]
09/26/2006 08:04 PM
Please respond
todiscussion@acfug.org
To
discussion@acfug.org
cc
Subject
Re: Re: [ACFUG Discuss] Client?
Session?
Yeah it depends on how you want your requests routed... it is
myunderstanding that if you want the machines to round robin
eachrequest then you need to do client variables, if you don't care
andyou just want users to stay on one server then you can use
sessions.On 9/26/06, Teddy Payne <[EMAIL PROTECTED]>
wrote:> Are you looking to store complex data in your shared scope?
If so, you need> some sort of sticky session solution. If
you are looking to store simple> data, using the datasource option of
client variable storeage would make it> easier to switch over between
servers.>> Teddy>>> On 9/26/06,
[EMAIL PROTECTED] <>
[EMAIL PROTECTED]> wrote:> >> > I'm
a little confused as to what scope of variables to use in our>
situation. We have a primary server and a 'backup' server in case
the> primary fails. Now that is the current situation.
Eventually the backup> will be replaced with a better machine and
the load will be balanced a> little more evenly. Currently the
balancing is done via Resonate software> (and no one seems to like it).
As far as 100% failover, I really don't see> that as a necessity,
these aren't banking applications. Also these servers> don't talk
to each other that I know of.> >> > TIA>
>> > Mary-Catherine> >>
-> > 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> >>
->>>>
--> >> Blog:
http://cfpayne.wordpress.com/> Atlanta CFUG:
http://www.acfug.org>>
-> 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>
---
Steven Rossweb application & interface
developerhttp://www.zerium.com[mobile] 404-488-4364[fax]
928-484-4364-To
unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserformFor more info, see
http://www.acfug.org/mailinglistsArchive @
http://www.mail-archive.com/discussion%40acfug.org/List hosted by
http://www.fusionlink.com-
Re: Re: [ACFUG Discuss] Client? Session?
client variables can only store simple data.http://livedocs.macromedia.com/coldfusion/7/htmldocs/1149.htmcompares the two. " In general it seems to me that the rule is that once a user is on a server, they are on the same server. " AKA sticky sessions. If using sticky sessions, you can use the session scope. Note that you can play the serialise/deserialise game on your complex data and use client vars, adds a bit of overhead, but this would allow you to use a 'more' load balanced setup with round-robins, etc. DKOn 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: In general it seems to me that the rule is that once a user is on a server, they are on the same server. Define complex data. I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet. We don't officially have any code written. mcg Steven Ross <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2006 08:04 PM Please respond to discussion@acfug.org To discussion@acfug.org cc Subject Re: Re: [ACFUG Discuss] Client? Session? Yeah it depends on how you want your requests routed... it is my understanding that if you want the machines to round robin each request then you need to do client variables, if you don't care and you just want users to stay on one server then you can use sessions. On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > Are you looking to store complex data in your shared scope? If so, you need > some sort of sticky session solution. If you are looking to store simple > data, using the datasource option of client variable storeage would make it > easier to switch over between servers. > > Teddy > > > On 9/26/06, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> wrote: > > > > I'm a little confused as to what scope of variables to use in our > situation. We have a primary server and a 'backup' server in case the > primary fails. Now that is the current situation. Eventually the backup > will be replaced with a better machine and the load will be balanced a > little more evenly. Currently the balancing is done via Resonate software > (and no one seems to like it). As far as 100% failover, I really don't see > that as a necessity, these aren't banking applications. Also these servers > don't talk to each other that I know of. > > > > TIA > > > > Mary-Catherine > > > - > > 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 > > > - > > > > -- > > > Blog: http://cfpayne.wordpress.com/ > Atlanta CFUG: http://www.acfug.org > > - > 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 > - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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 - - 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 - -- Douglas Knudsenhttp://www.cubicleman.comthis is my signature, like it? - 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 -
Re: Re: [ACFUG Discuss] Client? Session?
Complex data would be arrays, structures, queries, objects ..etc.Client variables can store simple data like strings, integers, boolean ...etc.I hope that makes sense,Teddy On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote: In general it seems to me that the rule is that once a user is on a server, they are on the same server. Define complex data. I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet. We don't officially have any code written. mcg Steven Ross <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2006 08:04 PM Please respond to discussion@acfug.org To discussion@acfug.org cc Subject Re: Re: [ACFUG Discuss] Client? Session? Yeah it depends on how you want your requests routed... it is my understanding that if you want the machines to round robin each request then you need to do client variables, if you don't care and you just want users to stay on one server then you can use sessions. On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > Are you looking to store complex data in your shared scope? If so, you need > some sort of sticky session solution. If you are looking to store simple > data, using the datasource option of client variable storeage would make it > easier to switch over between servers. > > Teddy > > > On 9/26/06, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> wrote: > > > > I'm a little confused as to what scope of variables to use in our > situation. We have a primary server and a 'backup' server in case the > primary fails. Now that is the current situation. Eventually the backup > will be replaced with a better machine and the load will be balanced a > little more evenly. Currently the balancing is done via Resonate software > (and no one seems to like it). As far as 100% failover, I really don't see > that as a necessity, these aren't banking applications. Also these servers > don't talk to each other that I know of. > > > > TIA > > > > Mary-Catherine > > > - > > 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 > > > - > > > > -- > > > Blog: http://cfpayne.wordpress.com/ > Atlanta CFUG: http://www.acfug.org > > - > 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 > - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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 - - 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 - -- Blog: http://cfpayne.wordpress.com/Atlanta CFUG: http://www.acfug.org - 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 -
Re: RE: Re: [ACFUG Discuss] Client? Session?
I stand corrected on the wddx thing... course there is still that size limit on a cookie and a google search returned this: 300 Cookies total 20 Cookies per server (not per page or site) 4K of data Per cookie (both the name and value of the cookie count towards this limit) On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Just as an aside - you can still store complex structures in client variables but you'll have to wddx them into a string and then store them into the client variable. Also, if you do this and you have your client variables stored in the database, you'll want to make sure your datasource is enabled to retrieve BLOB's without the 64k limit. One other thing, if you're running on MX in JRUN configuration (not standalone), you can share the sessions between servers (if I remember right). J2EE has clustering built in and I believe it supports the equivalent of a session state server. Allen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 27, 2006 9:22 AM To: discussion@acfug.org Subject: Re: Re: [ACFUG Discuss] Client? Session? In general it seems to me that the rule is that once a user is on a server, they are on the same server. Define complex data. I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet. We don't officially have any code written. mcg Steven Ross <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2006 08:04 PM Please respond to discussion@acfug.org To discussion@acfug.org cc Subject Re: Re: [ACFUG Discuss] Client? Session? Yeah it depends on how you want your requests routed... it is my understanding that if you want the machines to round robin each request then you need to do client variables, if you don't care and you just want users to stay on one server then you can use sessions. On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > Are you looking to store complex data in your shared scope? If so, you need > some sort of sticky session solution. If you are looking to store simple > data, using the datasource option of client variable storeage would make it > easier to switch over between servers. > > Teddy > > > On 9/26/06, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> wrote: > > > > I'm a little confused as to what scope of variables to use in our > situation. We have a primary server and a 'backup' server in case the > primary fails. Now that is the current situation. Eventually the backup > will be replaced with a better machine and the load will be balanced a > little more evenly. Currently the balancing is done via Resonate software > (and no one seems to like it). As far as 100% failover, I really don't see > that as a necessity, these aren't banking applications. Also these servers > don't talk to each other that I know of. > > > > TIA > > > > Mary-Catherine > > > - > > 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 > > > - > > > > -- > > > Blog: http://cfpayne.wordpress.com/ > Atlanta CFUG: http://www.acfug.org > > - > 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 > - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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 - - 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 - -
Re: Re: Re: [ACFUG Discuss] Client? Session?
You can't store anything that isn't your basic string/number in a cookie. There is also a size limit that a browser will store so sticking some giant wddx packet a cookie would probably not work. Since it sounds like you are using sticky sessions you could go ahead and use the server session scope. I would just verify that with whoever is setting up the cluster. -Steven On 9/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: In general it seems to me that the rule is that once a user is on a server, they are on the same server. Define complex data. I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet. We don't officially have any code written. mcg Steven Ross <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2006 08:04 PM Please respond to discussion@acfug.org To discussion@acfug.org cc Subject Re: Re: [ACFUG Discuss] Client? Session? Yeah it depends on how you want your requests routed... it is my understanding that if you want the machines to round robin each request then you need to do client variables, if you don't care and you just want users to stay on one server then you can use sessions. On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > Are you looking to store complex data in your shared scope? If so, you need > some sort of sticky session solution. If you are looking to store simple > data, using the datasource option of client variable storeage would make it > easier to switch over between servers. > > Teddy > > > On 9/26/06, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> wrote: > > > > I'm a little confused as to what scope of variables to use in our > situation. We have a primary server and a 'backup' server in case the > primary fails. Now that is the current situation. Eventually the backup > will be replaced with a better machine and the load will be balanced a > little more evenly. Currently the balancing is done via Resonate software > (and no one seems to like it). As far as 100% failover, I really don't see > that as a necessity, these aren't banking applications. Also these servers > don't talk to each other that I know of. > > > > TIA > > > > Mary-Catherine > > > - > > 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 > > > - > > > > -- > > > Blog: http://cfpayne.wordpress.com/ > Atlanta CFUG: http://www.acfug.org > > - > 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 > - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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 - - 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 - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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: Re: [ACFUG Discuss] Client? Session?
Just
as an aside - you can still store complex structures in client variables but
you'll have to wddx them into a string and then store them into the client
variable. Also, if you do this and you have your client variables stored
in the database, you'll want to make sure your datasource is enabled to retrieve
BLOB's without the 64k limit.
One
other thing, if you're running on MX in JRUN configuration (not standalone), you
can share the sessions between servers (if I remember right). J2EE has
clustering built in and I believe it supports the equivalent of a session state
server.
Allen
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of
[EMAIL PROTECTED]Sent: Wednesday, September
27, 2006 9:22 AMTo: discussion@acfug.orgSubject: Re: Re:
[ACFUG Discuss] Client? Session?In general it seems to me that the rule is that once a user is on a
server, they are on the same server. Define complex data. I
potentially see structures and possibly an occasional object in the shared
scope, but honestly I don't know yet. We don't officially have any code
written. mcg
Steven Ross
<[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED]
09/26/2006 08:04 PM
Please respond
todiscussion@acfug.org
To
discussion@acfug.org
cc
Subject
Re: Re: [ACFUG Discuss] Client?
Session?
Yeah it depends on how you want your requests routed... it is
myunderstanding that if you want the machines to round robin
eachrequest then you need to do client variables, if you don't care
andyou just want users to stay on one server then you can use
sessions.On 9/26/06, Teddy Payne <[EMAIL PROTECTED]>
wrote:> Are you looking to store complex data in your shared scope?
If so, you need> some sort of sticky session solution. If
you are looking to store simple> data, using the datasource option of
client variable storeage would make it> easier to switch over between
servers.>> Teddy>>> On 9/26/06,
[EMAIL PROTECTED] <>
[EMAIL PROTECTED]> wrote:> >> > I'm
a little confused as to what scope of variables to use in our>
situation. We have a primary server and a 'backup' server in case
the> primary fails. Now that is the current situation.
Eventually the backup> will be replaced with a better machine and
the load will be balanced a> little more evenly. Currently the
balancing is done via Resonate software> (and no one seems to like it).
As far as 100% failover, I really don't see> that as a necessity,
these aren't banking applications. Also these servers> don't talk
to each other that I know of.> >> > TIA>
>> > Mary-Catherine> >>
-> > 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> >>
->>>>
--> >> Blog:
http://cfpayne.wordpress.com/> Atlanta CFUG:
http://www.acfug.org>>
-> 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>
---
Steven Rossweb application & interface
developerhttp://www.zerium.com[mobile] 404-488-4364[fax]
928-484-4364-To
unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserformFor more info, see
http://www.acfug.org/mailinglistsArchive @
http://www.mail-archive.com/discussion%40acfug.org/List hosted by
http://www.fusionlink.com--
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/
Re: Re: [ACFUG Discuss] Client? Session?
In general it seems to me that the rule is that once a user is on a server, they are on the same server. Define complex data. I potentially see structures and possibly an occasional object in the shared scope, but honestly I don't know yet. We don't officially have any code written. mcg Steven Ross <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 09/26/2006 08:04 PM Please respond to discussion@acfug.org To discussion@acfug.org cc Subject Re: Re: [ACFUG Discuss] Client? Session? Yeah it depends on how you want your requests routed... it is my understanding that if you want the machines to round robin each request then you need to do client variables, if you don't care and you just want users to stay on one server then you can use sessions. On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote: > Are you looking to store complex data in your shared scope? If so, you need > some sort of sticky session solution. If you are looking to store simple > data, using the datasource option of client variable storeage would make it > easier to switch over between servers. > > Teddy > > > On 9/26/06, [EMAIL PROTECTED] < > [EMAIL PROTECTED]> wrote: > > > > I'm a little confused as to what scope of variables to use in our > situation. We have a primary server and a 'backup' server in case the > primary fails. Now that is the current situation. Eventually the backup > will be replaced with a better machine and the load will be balanced a > little more evenly. Currently the balancing is done via Resonate software > (and no one seems to like it). As far as 100% failover, I really don't see > that as a necessity, these aren't banking applications. Also these servers > don't talk to each other that I know of. > > > > TIA > > > > Mary-Catherine > > > - > > 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 > > > - > > > > -- > > > Blog: http://cfpayne.wordpress.com/ > Atlanta CFUG: http://www.acfug.org > > - > 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 > - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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 - - 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 -
Re: Re: [ACFUG Discuss] Client? Session?
Yeah it depends on how you want your requests routed... it is my understanding that if you want the machines to round robin each request then you need to do client variables, if you don't care and you just want users to stay on one server then you can use sessions. On 9/26/06, Teddy Payne <[EMAIL PROTECTED]> wrote: Are you looking to store complex data in your shared scope? If so, you need some sort of sticky session solution. If you are looking to store simple data, using the datasource option of client variable storeage would make it easier to switch over between servers. Teddy On 9/26/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > I'm a little confused as to what scope of variables to use in our situation. We have a primary server and a 'backup' server in case the primary fails. Now that is the current situation. Eventually the backup will be replaced with a better machine and the load will be balanced a little more evenly. Currently the balancing is done via Resonate software (and no one seems to like it). As far as 100% failover, I really don't see that as a necessity, these aren't banking applications. Also these servers don't talk to each other that I know of. > > TIA > > Mary-Catherine > - > 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 > - -- Blog: http://cfpayne.wordpress.com/ Atlanta CFUG: http://www.acfug.org - 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 - -- Steven Ross web application & interface developer http://www.zerium.com [mobile] 404-488-4364 [fax] 928-484-4364 - 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] Client? Session?
Are you looking to store complex data in your shared scope? If so, you need some sort of sticky session solution. If you are looking to store simple data, using the datasource option of client variable storeage would make it easier to switch over between servers. TeddyOn 9/26/06, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: I'm a little confused as to what scope of variables to use in our situation. We have a primary server and a 'backup' server in case the primary fails. Now that is the current situation. Eventually the backup will be replaced with a better machine and the load will be balanced a little more evenly. Currently the balancing is done via Resonate software (and no one seems to like it). As far as 100% failover, I really don't see that as a necessity, these aren't banking applications. Also these servers don't talk to each other that I know of. TIA Mary-Catherine - 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 - -- Blog: http://cfpayne.wordpress.com/Atlanta CFUG: http://www.acfug.org - 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 -
[ACFUG Discuss] Client? Session?
I'm a little confused as to what scope of variables to use in our situation. We have a primary server and a 'backup' server in case the primary fails. Now that is the current situation. Eventually the backup will be replaced with a better machine and the load will be balanced a little more evenly. Currently the balancing is done via Resonate software (and no one seems to like it). As far as 100% failover, I really don't see that as a necessity, these aren't banking applications. Also these servers don't talk to each other that I know of. TIA Mary-Catherine - 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 -
