Showing posts with label session. Show all posts
Showing posts with label session. Show all posts

Tuesday, August 27, 2013

AWS : Storing Session State


AWS SimpleDB, Memcache and DynamoDB can all be used.  DynamoDB is a good option as there is already a session provider for DynamoDB :
For SQL Server, you can also look at session management in SQL server for persistence  and use built in .net session provider modules.
You can also manage session state using AWS RDS for SQL Server, MySQL or Oracle.

Monday, August 12, 2013

Oracle MySQL Connect session time set

The session I am co-presenting at has been set for this time and place:

Session ID: CON4513
Session Title: Best Practices for Deploying MySQL on Amazon Web Services
Venue / Room: Hilton - Powell
Date and Time: 9/21/13 (Saturday), 16:00 - 17:00

Hope to see you there.

Wednesday, August 7, 2013

OpenWorld Oracle on AWS sessions

Here are the two sessions focused on Oracle on AWS at Oracle OpenWorld:

https://oracleus.activeevents.com/2013/connect/search.ww?eventRef=openworld#loadSearch-event=null&searchPhrase=Amazon&searchType=session&tc=0&sortBy=titleSort&p=&i(11180)=20800

I will be co-presenting this session: Best Practices for Running Oracle Database Instances on Amazon Web Services.

MySQL Session at MySQL Connect

Here are the two MySQL on AWS session an MySQL Connect in September:

https://oracleus.activeevents.com/2013/connect/search.ww?eventRef=mysqlconnect#loadSearch-event=null&searchPhrase=aws&searchType=session&tc=0&sortBy=&p=&i(11180)=20802

I will be co-presenting the Best Practices for Deploying MySQL on Amazon Web Services session.

Monday, April 22, 2013

Oracle WebLogic with AWS Auto Scaling

The question of using Oracle WebLogic with AWS Auto Scaling and propagation of session state is often asked.  Before getting into the details, let's look at the two ways of handling session state at the server layer (using cookies in the browser can be used as well):
1. Session stickiness : session data issue is to send all requests in a user session consistently to the same backend server. 
2. Session in database : Another solution is to keep the per-session data in a database.  Of course, AWS ElastiCache, SimpleDB or DynamoDB, or RDS.

If the session is stored in a database, nothing needs to be done when using Auto Scaling with WebLogic; for obvious reasons.


When sticky sessions is used, nothing needs to be done, but the reason is not so obvious so let's discuss it.

When a request comes into a WebLogic cluster via a load balancer (AWS ELB for example) or through Apache (mod_proxy_balancer plug in) the first time,  WebLogic creates an HTTP session on the primary node and also puts session state on a backup node. (You can provide guidance/control where to put the failure/backup).  If the server goes down that contains the primary WebLogic node, the new primary node will know where the backup session is stored and the session state will automatically get replicated to the new node.  So when AWS Auto Scaling is used there is nothing that needs to be done from an AWS perspective.