1 2 Previous Next 16 Replies Latest reply on Sep 4, 2007 4:00 PM by Pete Muir

    Seam-Managed Persistence Context

    jk;l jkl; Expert

      Could somebody please give specific examples of the problems that would happen if a SMPC should have been used but you incorrectly chose to use a different one instead (i.e. inject with @PersistenceContext instead of @In)?

        • 1. Re: Seam-Managed Persistence Context
          Norman Richards Master

          If you used another persistence context, your objects would become detached when the persistence context ended. (either at the end of the transaction or when the associated session bean is removed, depending on the persistence context type)

          When that happens, you can notice a couple of problems. First, you would no longer be able to save changes to the entity into the database without manually merging it back into the new persistence context. You might also get lazy instantiation errors if you try to access state/relations that had not yet been loaded.

          • 2. Re: Seam-Managed Persistence Context
            jk;l jkl; Expert

             

            If you used another persistence context, your objects would become detached when the persistence context ended.


            But doesn't what you said above apply to all persistence contexts, including the SMPC? What still confuses me is when does an SMPC end in comparison to, say, a SFSB extended PC? What's so special about SMPC...when is it created, when does it end, what requirements does it have in terms of associating itself with transactions, etc?

            Will my code look any different (I don't mean @In vs @PersistenceContext) in terms of the way I deal with entities from using another PC to using SMPC? (e.g. will I never have to do a merge again, what?) What should I keep in mind while I code so that I can actually take advantage of the fact that I'm using an SMPC?

            • 3. Re: Seam-Managed Persistence Context
              Christian Bauer Master

              The main advantages of a SMPC compared to an extended SFSB-bound PC are:

              - PC Injection works everywhere

              - PC Propagation rules are simplified, not bound to instantiation or transaction propagation (SFSB calling SLSB for example)

              - PC Scoping is simplified and tied into the conversation programming model of Seam

              - PCs can be atomic (manual flushing) without changes to your transaction assembly

              Advertisement: http://www.manning.com/bauer2

              • 4. Re: Seam-Managed Persistence Context
                jk;l jkl; Expert

                 

                You might also get lazy instantiation errors if you try to access state/relations that had not yet been loaded.


                Isn't the above the case for regular PCs as well...don't LIEs happen by definition when the relations haven't been loaded??

                I seem to get it even after having changed all my PCs to SMPCs. It happens on a lazily-initialized collection of an entity, and goes away when I set fetch=EAGER.

                What confuses me is that this same behavior would happen regardless of what PC I used...after all, wouldn't setting fetch=EAGER solve the problem in a regular PC as well as an SMPC? What's different about the SMPC from the LIE point of view?

                • 5. Re: Seam-Managed Persistence Context
                  Christian Bauer Master

                  You get a LIE because you didn't scope the PC correctly (no matter which PC). It's easier to scope a SMPC in a Seam application, usually to the conversation boundaries. This conversational programming model, applied correctly, with sometimes eager fetching of course, avoids all LIEs. A LIE is a design error, not something that happens randomly.

                  • 6. Re: Seam-Managed Persistence Context
                    jk;l jkl; Expert

                    What is meant by scoping the PC? Does that mean setting @In(scope=SESSION) or something like that...what would I set the scope to? But I doubt that's what you meant, because you said it applies to all PCs (i.e. those that use @PersistenceContext, which don't have a scope attribute, as opposed to @In)

                    Is there ever a case where eager fetching would need to be done using a regular PC but not when using an SMPC?

                    • 7. Re: Seam-Managed Persistence Context
                      Christian Bauer Master

                      Scoping means defining a Begin and an End of the persistence context, when it is opened and when it is closed. Seam has the @Begin and @End method annotations for that, which can automatically scope the SMPC to that conversation. So the SMPC would have the same scope as the Seam CONVERSATION context. A PC manages entity instances, they are attached to a PC (when they are loaded or stored).

                      Eager fetching is an orthogonal concern, you want it for a) SQL query optimization with joins and b) fetching of instances/values that you need outside of the PC scope, when an entity instance is considered detached.

                      I don't recommend that you try to learn this ad hoc, you really need to look at some docs and books. This is the fundamental programming model you need to understand.

                      • 8. Re: Seam-Managed Persistence Context
                        jk;l jkl; Expert

                        If I had a conversation with @Begin and @End but used a transaction or extended PC, could you describe specifically what the problem would be? What's an example of the disadvantage? (Of course I'll use the SMPC in this case, but I ask this question because it'll help clarify this issue for me.)

                        I don't recommend that you try to learn this ad hoc, you really need to look at some docs and books.


                        Could you please point me to some resources that will explain more about the SMPC, as I haven't been able to find anything too useful except for asking questions on this thread.

                        • 9. Re: Seam-Managed Persistence Context
                          Christian Bauer Master

                          http://www.manning.com/bauer2 :)

                          Even has a Seam bonus chapter that includes a discussion of SMPCs.

                          • 10. Re: Seam-Managed Persistence Context
                            Christian Bauer Master

                             

                            "lightbulb432" wrote:
                            If I had a conversation with @Begin and @End but used a transaction or extended PC, could you describe specifically what the problem would be? What's an example of the disadvantage? (Of course I'll use the SMPC in this case, but I ask this question because it'll help clarify this issue for me.)


                            That material spans three chapters in a book, probably 150 pages. You can't really break it down into a Q & A session.


                            • 11. Re: Seam-Managed Persistence Context
                              Norman Richards Master

                              I just got a copy in the mail yesterday from Manning - it looks great.

                              • 12. Re: Seam-Managed Persistence Context
                                Richard Stanford Newbie

                                Sorry to resurrect a dead thread, but it seems pretty relevant.

                                Is there a way to correctly use SMPCs to have a truly extended context for use with, say, a Session scope entity bean? I have a "currentUser" bean that's in session scope, and it has references to various other components - I'm looking for a way to be able to reference these in pages whether or not they've previously been loaded. However, everything seems to be aimed at mid-life conversation scoped objects.

                                Would I be better off simply storing the ID in session scope and doing a factory every time? That seems a little intensive, but at the same time I don't want to have to create an action for every page just to create a persistence context to merge() the currentUser object to.

                                What's the correct thing to do here?

                                • 13. Re: Seam-Managed Persistence Context
                                  Pete Muir Master

                                   

                                  "rjstanford" wrote:
                                  Would I be better off simply storing the ID in session scope and doing a factory every time? That seems a little intensive, but at the same time I don't want to have to create an action for every page just to create a persistence context to merge() the currentUser object to.


                                  This would be my approach, but it depends on how often you need the currentUser object - bear in mind that the object is probably in the Hibernate 2nd level cache anyway. It will also play nice with all your other objects in this scenario. Otherwise you can create a SESSION scoped SMPC (just set the scope in components.xml) - but it will be a different SMPC from your normal one, so you'll get exceptions if you try to manage the wrong object in the wrong PC.

                                  • 14. Re: Seam-Managed Persistence Context
                                    Richard Stanford Newbie

                                    Fantastic, that's the way I'll proceed then. For something like this, where would you suggest having the factory? I don't really like adding that into the datamodel piece (although that seems to be very common for example-scale apps); is it more realistic to have a generic Factory class that contains all of these types of factories, or is it better to have smaller, more specific ones (or should I just embrace the future and have a factory method on the entity bean)?

                                    Thanks for the advice, by the way. Very useful. It also seems like for most conversations I should be using SMPC rather than PersistenceContext (from this and other threads) - is that a valid take-away from this as well?

                                    1 2 Previous Next