Performance issue related to Conversation scope

[gimpy21]

I have a CONVERSATION scoped bean that holds a Map of many items (over 1k). The bean works quickly when the Map is not populated OR the scope is set to SESSION. The problem arises when the Map is populated AND the scope is set to CONVERSATION. The problem is that a call is executed but my CPU usage goes through the roof and the page fails to update for over 10 seconds. So I call a method, debug info shows it immediately completes, but Seam appears to hate the Map of many items at that scope. I assume it is reading the bean from a scope cache and writing it back to the cache or something which costs it so much CPU time. Has anyone else run into something similar? I googled a bit and searched this forum, but I failed to find anything that really matched my situation.

[andygibson.contact.andygibson.net]

Do you have some kind of example to demonstrate the problem?

I just put a big map in my bean without problems. Does the map hold entities, is it outjected etc

Cheers,

Andy

[gimpy21]

Hello Andy. The Map<String, Location> is loaded on bean creation. Location is an entity with 2 or 3 instance variables within it. The Map is not injected or outjected. The page the bean was created for is used to select geographical territories and the Map is used for pulling ranges from (like zip codes within a state for example). It has well over 10k Location entities from the database, but they are extremely small and marked with Seam's @ReadOnly and Hibernate's Entity(mutable=false) (which did nothing to help btw). I'm quite certain that I'm going to have to have all of the entities in memory at one time or another for verification that all locations have been acccounted for.

[gimpy21]

I would also like to add that it works at PAGE scope flawlessly like it does at SESSION scope. I also have these two annotations on the bean:

@Stateful
@TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)

[cpopetz]

Any performance issues that exist on Conversational components after upgrading to 2.0.2 and not on a similar component in a different scope are possibly due to JBSEAM-2917

If you are ok building seam from source, try the patch attached to that jira report.

[gimpy21]

Hi Clint. In your bug report, the first sentence is a bit confusing when you say the cache gets recreated every time it fails to find a given class. When would it fail to find a given class that is not injected in a conversation-scoped bean? In my example, would my Map be a part of those classes that are failed to be found? I looked in the source for Seam 2.0.1.GA and it has the same issue that you patched. I'm downloading the source for 2.0.0.GA now to see if the method changed at all over the last few versions.

[gimpy21]

Bah. After looking at the patch, I realize what you meant. I'll apply the patch and see how it goes. The method in 2.0.0.GA is exactly the same.

[gimpy21]

I know it's a month old, but I wanted to close this one out for anyone else that may come by it. The patch you submitted did the trick, but was modified some for the official Seam release. The ticket says it was incorporated into 2.1.0.BETA1. Thanks for the fix.