Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

HTTP Session in AEM

Avatar

Avatar
Give Back
Level 1
priyankak11
Level 1

Likes

2 likes

Total Posts

5 posts

Correct Reply

0 solutions
Top badges earned
Give Back
Ignite 1
Boost 1
View profile

Avatar
Give Back
Level 1
priyankak11
Level 1

Likes

2 likes

Total Posts

5 posts

Correct Reply

0 solutions
Top badges earned
Give Back
Ignite 1
Boost 1
View profile
priyankak11
Level 1

02-06-2021

We have requirement to store a long string (end-user specific) in a cookie but because of the size limitation of the cookie, we are not able to store it.  We are required to send this String with every call to the database.  We are using MarkLogic database here. Please suggest what will be drawback of using HTTP Session to store that?

Also,  is there any other way to store it? We have multiple AEM instances in production.

Thank you.

Accepted Solutions (1)

Accepted Solutions (1)

Avatar

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,112 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile

Avatar
Coach
Employee
Jörg_Hoh
Employee

Likes

1,112 likes

Total Posts

3,145 posts

Correct Reply

1,072 solutions
Top badges earned
Coach
Give back 600
Ignite 5
Ignite 3
Ignite 1
View profile
Jörg_Hoh
Employee

03-06-2021

 

I would question the application design when you constantly need to send more than 4k from the client to the server. Does this payload change with every request?

If not, the first natural approach is a server-side session, but this design does not scale at all, and is often problematic in terms of failover, its more and more discouraged. AEM does not encourage to use server-side sessions, because that as a really bad impact on your application performance, when you need to render a lot requests and cannot cache them. Naturally your publish instances will become a bottleneck.

 

Why don't you store that data once in the database and the browser just sends an ID in a cookie, so the application can reference it?

Answers (3)

Answers (3)

Avatar

Avatar
Give Back
Level 1
priyankak11
Level 1

Likes

2 likes

Total Posts

5 posts

Correct Reply

0 solutions
Top badges earned
Give Back
Ignite 1
Boost 1
View profile

Avatar
Give Back
Level 1
priyankak11
Level 1

Likes

2 likes

Total Posts

5 posts

Correct Reply

0 solutions
Top badges earned
Give Back
Ignite 1
Boost 1
View profile
priyankak11
Level 1

02-06-2021

I am not Using session because session will slow down the performace and using HTTP Session is not recommended by Adobe.

Avatar

Avatar
Validate 1
MVP
Umesh_Thakur
MVP

Likes

147 likes

Total Posts

157 posts

Correct Reply

53 solutions
Top badges earned
Validate 1
Applaud 25
Ignite 3
Ignite 1
Give Back 5
View profile

Avatar
Validate 1
MVP
Umesh_Thakur
MVP

Likes

147 likes

Total Posts

157 posts

Correct Reply

53 solutions
Top badges earned
Validate 1
Applaud 25
Ignite 3
Ignite 1
Give Back 5
View profile
Umesh_Thakur
MVP

02-06-2021

If cookie has some limitation in your case then why did you not go with the sessionStorage and localStorage for the same purpose if you go with javascript way. In java you can easily take help from HTTP session api itself for the same.

 

Hope this will help.

Umesh Thakur

Avatar

Avatar
Springboard
Level 7
KiranVedantam1992
Level 7

Likes

169 likes

Total Posts

177 posts

Correct Reply

54 solutions
Top badges earned
Springboard
Give Back 5
Ignite 1
Affirm 50
Validate 1
View profile

Avatar
Springboard
Level 7
KiranVedantam1992
Level 7

Likes

169 likes

Total Posts

177 posts

Correct Reply

54 solutions
Top badges earned
Springboard
Give Back 5
Ignite 1
Affirm 50
Validate 1
View profile
KiranVedantam1992
Level 7

02-06-2021

Hi @priyankak11,

 

What is the size of the cookie? Which places did you try saving them? Did you try both java and java-script?

 

Thanks,

Kiran Vedantam.