[aerogear-dev] TODO server app observations

Bruno Oliveira bruno at abstractj.org
Wed Oct 17 14:16:10 EDT 2012


Awesome! Few free to send more PRs and file Jiras as needed.  


--  
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile



On Monday, October 15, 2012 at 5:58 PM, Marko Strukelj wrote:

> We have fixed this very quickly:  
>  
> - https://github.com/aerogear/TODO/pull/4
> - https://github.com/aerogear/TODO/pull/6
>  
> Regarding serializers, it doesn't actually have to be build-time generation (that usually gives you best performance). There are other options.
>  
> Curiously, the second fix required after initial one (https://github.com/aerogear/TODO/pull/6) exposes the need for persistence layer to be in sync with serialization layer, using fine-tuned queries. Seems to me there is some opportunity here for hiding plumbing on both of these layers.
>  
> ----- Original Message -----
> > These seems like good points for discussion and/or issues for jira.
> >  
> > The only one that concerns me with my quick look is generating
> > serializers at compile time. Build time generation is one of the
> > area's we wanted to avoid in general.
> >  
> > For the other items I think jira's would be appropriate as your
> > understanding of the AS and SLSB's would be useful to capture these
> > concerns or potential bugs.
> >  
> > -Jay
> >  
> > On Oct 9, 2012, at 10:25 AM, Marko Strukelj wrote:
> >  
> > >  
> > > I’ve been looking into TODO app to get a better understanding of
> > > how aerogear.js works in a browser, and how we could abstract
> > > server-side into something we could call ‘aerogear-server’ as
> > > opposed to TODO app.
> > >  
> > > Here are some observations:
> > >  
> > >  
> > > - The *Endpoint classes are SLSB, but use extended persistence
> > > context [1]
> > >  
> > > Extended persistence context is not supported on Stateless session
> > > beans per JPA spec [2].
> > >  
> > > The reason is that stateless beans are not singletons or contextual
> > > objects (i.e. CDI scoped) but are pooled instances, so you can
> > > receive a different one for each call that you make. That would
> > > mean that you could get a different EntityManager instance each
> > > time, with possible uncommitted state from another method call by
> > > another client. It would be impossible to do consistent
> > > persistence across multiple invocations with that kind of random
> > > behaviour. Also if ten requests hit at the same time there would
> > > be ten instances of EntityManager, and ten separate persistence
> > > contexts, and since they are extended and ‘never’ cleared (EJB
> > > container decides, behaviour is unspecified) - we have ten memory
> > > leaks.
> > >  
> > > It looks like AS7 doesn’t much care if you use EXTENDED annotation
> > > in a SLSB - it will happily comply (and create a memory leak for
> > > you), whereas some other app servers will break on deployment [3],
> > > and Scott Marlow concedes it should probably be a deployment error
> > > [4], so maybe one day this would also break on AS7.
> > >  
> > >  
> > >  
> > > - Method joinTransaction() only makes sense on application-managed
> > > entity manager
> > >  
> > > We are using container-managed entity manager - one that gets
> > > injected - as opposed to one retrieved by calling
> > > EntityManagerFactory.createEntityManager() method (that would be
> > > application-managed). Call to joinTransaction() is therefore a
> > > no-op, and should be removed [5][6][7].
> > >  
> > >  
> > > - Custom serializers look like plumbing
> > > Would be good to have a way to autogenerate them during compile
> > > based on annotations. Also, for the purpose of autogenerating
> > > entities for the client based on server data definitions
> > > (metadata) we need to use those same definitions during
> > > serialization. This is the most obvious point where
> > > aerogear-server as a server-side framework comes to play.
> > >  
> > >  
> > > [1]
> > > https://github.com/aerogear/TODO/tree/picketbox/server/src/main/java/org/aerogear/todo/server/rest
> > > [2]
> > > http://stackoverflow.com/questions/2547817/what-is-the-difference-between-transaction-scoped-persistence-context-and-extend
> > > [3] https://community.jboss.org/thread/196404
> > > [4] https://community.jboss.org/message/721988#721988
> > > [5]
> > > http://docs.oracle.com/javaee/6/api/javax/persistence/EntityManager.html#joinTransaction()
> > > [6] http://docs.oracle.com/javaee/5/tutorial/doc/bnbqw.html
> > > [7]
> > > http://docs.jboss.org/hibernate/orm/4.0/hem/en-US/html/architecture.html#d0e134
> > >  
> > >  
> > > - marko
> > >  
> > >  
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > >  
> >  
> >  
> >  
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >  
>  
>  
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org (mailto:aerogear-dev at lists.jboss.org)
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20121017/bf764324/attachment.html 


More information about the aerogear-dev mailing list