Destroy all session scoped bean of a class
Is there any way to destroy all created session scoped bean of a particular class (and let spring recreate when needed) ?
For example, 2 users visit the application, and then there will be 1 bean for each of the user. I would like to destroy all these 2 beans.
Use case:
a admin is updating the menu bar. menu bar list data are stored in a session scoped bean. the admin's bean should be destroyed and the menu bar should be updated. and of course the others' menu should be updated as well, so the others bean should be destroyed as well.
note 1: different user may see different menu, so the bean is session scoped, not singleton.
note 2: i do not want to invalidate whole session of the user, but just only that bean
i found this way to destroy the current scope bean. but i am not able to destroy bean from other session.
((ScopedObject) myBean).removeFromScope();
Thanks a lot !!
java spring spring-boot javabeans session-scope
add a comment |
Is there any way to destroy all created session scoped bean of a particular class (and let spring recreate when needed) ?
For example, 2 users visit the application, and then there will be 1 bean for each of the user. I would like to destroy all these 2 beans.
Use case:
a admin is updating the menu bar. menu bar list data are stored in a session scoped bean. the admin's bean should be destroyed and the menu bar should be updated. and of course the others' menu should be updated as well, so the others bean should be destroyed as well.
note 1: different user may see different menu, so the bean is session scoped, not singleton.
note 2: i do not want to invalidate whole session of the user, but just only that bean
i found this way to destroy the current scope bean. but i am not able to destroy bean from other session.
((ScopedObject) myBean).removeFromScope();
Thanks a lot !!
java spring spring-boot javabeans session-scope
The proper fix would be to avoid storing this non-session-related data in the session. Or at the very least to check if there was an update when accessing it, and refresh it if needed.
– JB Nizet
Nov 11 at 10:22
I wanted to do some caching for the menu, and different user may have different menu (so i guess this is session-related? please tell me if my understanding is wrong). so what i can think to increase the efficiency is to only refreshing the menu data when needed (updated)
– Hon Lun Chan
Nov 11 at 10:26
It's not really session-related because the data it contains isn't valid for the duration of the session (as your problem shows), and its data isn't controlled by the user which the session belongs to. Again, I would make everything stateless. If there is really a performance problem, then cache the whole configuration in a singleton bean, and compute the user-specific menu whenever needed. If there is still a performance problem, store the menu in the session, but check if it must be recomputed every time it's displayed.
– JB Nizet
Nov 11 at 10:31
i see. so probably i should follow your approach instead of messing with the user session! thanks for your suggestion !
– Hon Lun Chan
Nov 11 at 14:24
You cannot touch a session from another users session. If that would be possible that would be quitte some security hole. As @JBNizet pointed out the data isn’t really session related, so just put it in a cache and clear that after the updating.
– M. Deinum
Nov 12 at 7:29
add a comment |
Is there any way to destroy all created session scoped bean of a particular class (and let spring recreate when needed) ?
For example, 2 users visit the application, and then there will be 1 bean for each of the user. I would like to destroy all these 2 beans.
Use case:
a admin is updating the menu bar. menu bar list data are stored in a session scoped bean. the admin's bean should be destroyed and the menu bar should be updated. and of course the others' menu should be updated as well, so the others bean should be destroyed as well.
note 1: different user may see different menu, so the bean is session scoped, not singleton.
note 2: i do not want to invalidate whole session of the user, but just only that bean
i found this way to destroy the current scope bean. but i am not able to destroy bean from other session.
((ScopedObject) myBean).removeFromScope();
Thanks a lot !!
java spring spring-boot javabeans session-scope
Is there any way to destroy all created session scoped bean of a particular class (and let spring recreate when needed) ?
For example, 2 users visit the application, and then there will be 1 bean for each of the user. I would like to destroy all these 2 beans.
Use case:
a admin is updating the menu bar. menu bar list data are stored in a session scoped bean. the admin's bean should be destroyed and the menu bar should be updated. and of course the others' menu should be updated as well, so the others bean should be destroyed as well.
note 1: different user may see different menu, so the bean is session scoped, not singleton.
note 2: i do not want to invalidate whole session of the user, but just only that bean
i found this way to destroy the current scope bean. but i am not able to destroy bean from other session.
((ScopedObject) myBean).removeFromScope();
Thanks a lot !!
java spring spring-boot javabeans session-scope
java spring spring-boot javabeans session-scope
asked Nov 11 at 10:18
Hon Lun Chan
3911
3911
The proper fix would be to avoid storing this non-session-related data in the session. Or at the very least to check if there was an update when accessing it, and refresh it if needed.
– JB Nizet
Nov 11 at 10:22
I wanted to do some caching for the menu, and different user may have different menu (so i guess this is session-related? please tell me if my understanding is wrong). so what i can think to increase the efficiency is to only refreshing the menu data when needed (updated)
– Hon Lun Chan
Nov 11 at 10:26
It's not really session-related because the data it contains isn't valid for the duration of the session (as your problem shows), and its data isn't controlled by the user which the session belongs to. Again, I would make everything stateless. If there is really a performance problem, then cache the whole configuration in a singleton bean, and compute the user-specific menu whenever needed. If there is still a performance problem, store the menu in the session, but check if it must be recomputed every time it's displayed.
– JB Nizet
Nov 11 at 10:31
i see. so probably i should follow your approach instead of messing with the user session! thanks for your suggestion !
– Hon Lun Chan
Nov 11 at 14:24
You cannot touch a session from another users session. If that would be possible that would be quitte some security hole. As @JBNizet pointed out the data isn’t really session related, so just put it in a cache and clear that after the updating.
– M. Deinum
Nov 12 at 7:29
add a comment |
The proper fix would be to avoid storing this non-session-related data in the session. Or at the very least to check if there was an update when accessing it, and refresh it if needed.
– JB Nizet
Nov 11 at 10:22
I wanted to do some caching for the menu, and different user may have different menu (so i guess this is session-related? please tell me if my understanding is wrong). so what i can think to increase the efficiency is to only refreshing the menu data when needed (updated)
– Hon Lun Chan
Nov 11 at 10:26
It's not really session-related because the data it contains isn't valid for the duration of the session (as your problem shows), and its data isn't controlled by the user which the session belongs to. Again, I would make everything stateless. If there is really a performance problem, then cache the whole configuration in a singleton bean, and compute the user-specific menu whenever needed. If there is still a performance problem, store the menu in the session, but check if it must be recomputed every time it's displayed.
– JB Nizet
Nov 11 at 10:31
i see. so probably i should follow your approach instead of messing with the user session! thanks for your suggestion !
– Hon Lun Chan
Nov 11 at 14:24
You cannot touch a session from another users session. If that would be possible that would be quitte some security hole. As @JBNizet pointed out the data isn’t really session related, so just put it in a cache and clear that after the updating.
– M. Deinum
Nov 12 at 7:29
The proper fix would be to avoid storing this non-session-related data in the session. Or at the very least to check if there was an update when accessing it, and refresh it if needed.
– JB Nizet
Nov 11 at 10:22
The proper fix would be to avoid storing this non-session-related data in the session. Or at the very least to check if there was an update when accessing it, and refresh it if needed.
– JB Nizet
Nov 11 at 10:22
I wanted to do some caching for the menu, and different user may have different menu (so i guess this is session-related? please tell me if my understanding is wrong). so what i can think to increase the efficiency is to only refreshing the menu data when needed (updated)
– Hon Lun Chan
Nov 11 at 10:26
I wanted to do some caching for the menu, and different user may have different menu (so i guess this is session-related? please tell me if my understanding is wrong). so what i can think to increase the efficiency is to only refreshing the menu data when needed (updated)
– Hon Lun Chan
Nov 11 at 10:26
It's not really session-related because the data it contains isn't valid for the duration of the session (as your problem shows), and its data isn't controlled by the user which the session belongs to. Again, I would make everything stateless. If there is really a performance problem, then cache the whole configuration in a singleton bean, and compute the user-specific menu whenever needed. If there is still a performance problem, store the menu in the session, but check if it must be recomputed every time it's displayed.
– JB Nizet
Nov 11 at 10:31
It's not really session-related because the data it contains isn't valid for the duration of the session (as your problem shows), and its data isn't controlled by the user which the session belongs to. Again, I would make everything stateless. If there is really a performance problem, then cache the whole configuration in a singleton bean, and compute the user-specific menu whenever needed. If there is still a performance problem, store the menu in the session, but check if it must be recomputed every time it's displayed.
– JB Nizet
Nov 11 at 10:31
i see. so probably i should follow your approach instead of messing with the user session! thanks for your suggestion !
– Hon Lun Chan
Nov 11 at 14:24
i see. so probably i should follow your approach instead of messing with the user session! thanks for your suggestion !
– Hon Lun Chan
Nov 11 at 14:24
You cannot touch a session from another users session. If that would be possible that would be quitte some security hole. As @JBNizet pointed out the data isn’t really session related, so just put it in a cache and clear that after the updating.
– M. Deinum
Nov 12 at 7:29
You cannot touch a session from another users session. If that would be possible that would be quitte some security hole. As @JBNizet pointed out the data isn’t really session related, so just put it in a cache and clear that after the updating.
– M. Deinum
Nov 12 at 7:29
add a comment |
1 Answer
1
active
oldest
votes
Destroying beans and recreating them seems overkill and a little messy too.
For such approaches I would favor events and Spring provides a Spring Event API (spring-context
dependency).
You could inject an ApplicationEventPublisher
instance in the bean class that provokes the state change for some other beans and these beans could register a even listener ( @EventListener(condition = "..."))
to read this change event.
For example the publisher :
@Component
public class PublisherBean
private final ApplicationEventPublisher publisher;
@Autowired
public PublisherBean(ApplicationEventPublisher publisher) ...
public void createOrder(Order order)
// ....
this.publisher.publishEvent(new OrderCreatedEvent(order));
Subscribers/Listeners :
@Component
public class ListenerBean
@EventListener(condition = "#creationEvent.awesome")
public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent)
...
You could see more information here.
Are you sure that this would work with session-scoped beans? Those only really exist while a request is being processed for the session.
– JB Nizet
Nov 11 at 10:34
Honestly never tested with session scoped beans as generally I banish them and banish data in session. If the OP doesn't test this way, I could give it a go on a sample project.
– davidxxx
Nov 11 at 10:37
tried and seems that it does not pass through session scoped bean (?) i am not sure if i write correctly thoughapplicationEventPublisher.publishEvent(new CmsMenuUpdatedEvent(this));
@EventListener() public void handleMenuUpdate(CmsMenuUpdatedEvent event)
but thanks for telling me about this amazing event listener function !!
– Hon Lun Chan
Nov 11 at 14:20
and one more question, when would you choose for publishing a event and handling in the listener, or when would you choose for directly call the method from the listener ? update: actually i can make another research :) thanks anyway
– Hon Lun Chan
Nov 11 at 14:29
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53247752%2fdestroy-all-session-scoped-bean-of-a-class%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Destroying beans and recreating them seems overkill and a little messy too.
For such approaches I would favor events and Spring provides a Spring Event API (spring-context
dependency).
You could inject an ApplicationEventPublisher
instance in the bean class that provokes the state change for some other beans and these beans could register a even listener ( @EventListener(condition = "..."))
to read this change event.
For example the publisher :
@Component
public class PublisherBean
private final ApplicationEventPublisher publisher;
@Autowired
public PublisherBean(ApplicationEventPublisher publisher) ...
public void createOrder(Order order)
// ....
this.publisher.publishEvent(new OrderCreatedEvent(order));
Subscribers/Listeners :
@Component
public class ListenerBean
@EventListener(condition = "#creationEvent.awesome")
public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent)
...
You could see more information here.
Are you sure that this would work with session-scoped beans? Those only really exist while a request is being processed for the session.
– JB Nizet
Nov 11 at 10:34
Honestly never tested with session scoped beans as generally I banish them and banish data in session. If the OP doesn't test this way, I could give it a go on a sample project.
– davidxxx
Nov 11 at 10:37
tried and seems that it does not pass through session scoped bean (?) i am not sure if i write correctly thoughapplicationEventPublisher.publishEvent(new CmsMenuUpdatedEvent(this));
@EventListener() public void handleMenuUpdate(CmsMenuUpdatedEvent event)
but thanks for telling me about this amazing event listener function !!
– Hon Lun Chan
Nov 11 at 14:20
and one more question, when would you choose for publishing a event and handling in the listener, or when would you choose for directly call the method from the listener ? update: actually i can make another research :) thanks anyway
– Hon Lun Chan
Nov 11 at 14:29
add a comment |
Destroying beans and recreating them seems overkill and a little messy too.
For such approaches I would favor events and Spring provides a Spring Event API (spring-context
dependency).
You could inject an ApplicationEventPublisher
instance in the bean class that provokes the state change for some other beans and these beans could register a even listener ( @EventListener(condition = "..."))
to read this change event.
For example the publisher :
@Component
public class PublisherBean
private final ApplicationEventPublisher publisher;
@Autowired
public PublisherBean(ApplicationEventPublisher publisher) ...
public void createOrder(Order order)
// ....
this.publisher.publishEvent(new OrderCreatedEvent(order));
Subscribers/Listeners :
@Component
public class ListenerBean
@EventListener(condition = "#creationEvent.awesome")
public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent)
...
You could see more information here.
Are you sure that this would work with session-scoped beans? Those only really exist while a request is being processed for the session.
– JB Nizet
Nov 11 at 10:34
Honestly never tested with session scoped beans as generally I banish them and banish data in session. If the OP doesn't test this way, I could give it a go on a sample project.
– davidxxx
Nov 11 at 10:37
tried and seems that it does not pass through session scoped bean (?) i am not sure if i write correctly thoughapplicationEventPublisher.publishEvent(new CmsMenuUpdatedEvent(this));
@EventListener() public void handleMenuUpdate(CmsMenuUpdatedEvent event)
but thanks for telling me about this amazing event listener function !!
– Hon Lun Chan
Nov 11 at 14:20
and one more question, when would you choose for publishing a event and handling in the listener, or when would you choose for directly call the method from the listener ? update: actually i can make another research :) thanks anyway
– Hon Lun Chan
Nov 11 at 14:29
add a comment |
Destroying beans and recreating them seems overkill and a little messy too.
For such approaches I would favor events and Spring provides a Spring Event API (spring-context
dependency).
You could inject an ApplicationEventPublisher
instance in the bean class that provokes the state change for some other beans and these beans could register a even listener ( @EventListener(condition = "..."))
to read this change event.
For example the publisher :
@Component
public class PublisherBean
private final ApplicationEventPublisher publisher;
@Autowired
public PublisherBean(ApplicationEventPublisher publisher) ...
public void createOrder(Order order)
// ....
this.publisher.publishEvent(new OrderCreatedEvent(order));
Subscribers/Listeners :
@Component
public class ListenerBean
@EventListener(condition = "#creationEvent.awesome")
public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent)
...
You could see more information here.
Destroying beans and recreating them seems overkill and a little messy too.
For such approaches I would favor events and Spring provides a Spring Event API (spring-context
dependency).
You could inject an ApplicationEventPublisher
instance in the bean class that provokes the state change for some other beans and these beans could register a even listener ( @EventListener(condition = "..."))
to read this change event.
For example the publisher :
@Component
public class PublisherBean
private final ApplicationEventPublisher publisher;
@Autowired
public PublisherBean(ApplicationEventPublisher publisher) ...
public void createOrder(Order order)
// ....
this.publisher.publishEvent(new OrderCreatedEvent(order));
Subscribers/Listeners :
@Component
public class ListenerBean
@EventListener(condition = "#creationEvent.awesome")
public void handleOrderCreatedEvent(CreationEvent<Order> creationEvent)
...
You could see more information here.
edited Nov 11 at 10:32
answered Nov 11 at 10:27
davidxxx
63.3k55993
63.3k55993
Are you sure that this would work with session-scoped beans? Those only really exist while a request is being processed for the session.
– JB Nizet
Nov 11 at 10:34
Honestly never tested with session scoped beans as generally I banish them and banish data in session. If the OP doesn't test this way, I could give it a go on a sample project.
– davidxxx
Nov 11 at 10:37
tried and seems that it does not pass through session scoped bean (?) i am not sure if i write correctly thoughapplicationEventPublisher.publishEvent(new CmsMenuUpdatedEvent(this));
@EventListener() public void handleMenuUpdate(CmsMenuUpdatedEvent event)
but thanks for telling me about this amazing event listener function !!
– Hon Lun Chan
Nov 11 at 14:20
and one more question, when would you choose for publishing a event and handling in the listener, or when would you choose for directly call the method from the listener ? update: actually i can make another research :) thanks anyway
– Hon Lun Chan
Nov 11 at 14:29
add a comment |
Are you sure that this would work with session-scoped beans? Those only really exist while a request is being processed for the session.
– JB Nizet
Nov 11 at 10:34
Honestly never tested with session scoped beans as generally I banish them and banish data in session. If the OP doesn't test this way, I could give it a go on a sample project.
– davidxxx
Nov 11 at 10:37
tried and seems that it does not pass through session scoped bean (?) i am not sure if i write correctly thoughapplicationEventPublisher.publishEvent(new CmsMenuUpdatedEvent(this));
@EventListener() public void handleMenuUpdate(CmsMenuUpdatedEvent event)
but thanks for telling me about this amazing event listener function !!
– Hon Lun Chan
Nov 11 at 14:20
and one more question, when would you choose for publishing a event and handling in the listener, or when would you choose for directly call the method from the listener ? update: actually i can make another research :) thanks anyway
– Hon Lun Chan
Nov 11 at 14:29
Are you sure that this would work with session-scoped beans? Those only really exist while a request is being processed for the session.
– JB Nizet
Nov 11 at 10:34
Are you sure that this would work with session-scoped beans? Those only really exist while a request is being processed for the session.
– JB Nizet
Nov 11 at 10:34
Honestly never tested with session scoped beans as generally I banish them and banish data in session. If the OP doesn't test this way, I could give it a go on a sample project.
– davidxxx
Nov 11 at 10:37
Honestly never tested with session scoped beans as generally I banish them and banish data in session. If the OP doesn't test this way, I could give it a go on a sample project.
– davidxxx
Nov 11 at 10:37
tried and seems that it does not pass through session scoped bean (?) i am not sure if i write correctly though
applicationEventPublisher.publishEvent(new CmsMenuUpdatedEvent(this));
@EventListener() public void handleMenuUpdate(CmsMenuUpdatedEvent event)
but thanks for telling me about this amazing event listener function !!– Hon Lun Chan
Nov 11 at 14:20
tried and seems that it does not pass through session scoped bean (?) i am not sure if i write correctly though
applicationEventPublisher.publishEvent(new CmsMenuUpdatedEvent(this));
@EventListener() public void handleMenuUpdate(CmsMenuUpdatedEvent event)
but thanks for telling me about this amazing event listener function !!– Hon Lun Chan
Nov 11 at 14:20
and one more question, when would you choose for publishing a event and handling in the listener, or when would you choose for directly call the method from the listener ? update: actually i can make another research :) thanks anyway
– Hon Lun Chan
Nov 11 at 14:29
and one more question, when would you choose for publishing a event and handling in the listener, or when would you choose for directly call the method from the listener ? update: actually i can make another research :) thanks anyway
– Hon Lun Chan
Nov 11 at 14:29
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53247752%2fdestroy-all-session-scoped-bean-of-a-class%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The proper fix would be to avoid storing this non-session-related data in the session. Or at the very least to check if there was an update when accessing it, and refresh it if needed.
– JB Nizet
Nov 11 at 10:22
I wanted to do some caching for the menu, and different user may have different menu (so i guess this is session-related? please tell me if my understanding is wrong). so what i can think to increase the efficiency is to only refreshing the menu data when needed (updated)
– Hon Lun Chan
Nov 11 at 10:26
It's not really session-related because the data it contains isn't valid for the duration of the session (as your problem shows), and its data isn't controlled by the user which the session belongs to. Again, I would make everything stateless. If there is really a performance problem, then cache the whole configuration in a singleton bean, and compute the user-specific menu whenever needed. If there is still a performance problem, store the menu in the session, but check if it must be recomputed every time it's displayed.
– JB Nizet
Nov 11 at 10:31
i see. so probably i should follow your approach instead of messing with the user session! thanks for your suggestion !
– Hon Lun Chan
Nov 11 at 14:24
You cannot touch a session from another users session. If that would be possible that would be quitte some security hole. As @JBNizet pointed out the data isn’t really session related, so just put it in a cache and clear that after the updating.
– M. Deinum
Nov 12 at 7:29