Destroy all session scoped bean of a class










0














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 !!










share|improve this question





















  • 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















0














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 !!










share|improve this question





















  • 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













0












0








0







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 !!










share|improve this question













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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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
















  • 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












1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer






















  • 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 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











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
);



);













draft saved

draft discarded


















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









0














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.






share|improve this answer






















  • 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 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
















0














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.






share|improve this answer






















  • 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 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














0












0








0






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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








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 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

















  • 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 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
















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


















draft saved

draft discarded
















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Use pre created SQLite database for Android project in kotlin

Darth Vader #20

Ondo