Re: [aerogear-dev] TODO server app observations

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/... > > [2] > > http://stackoverflow.com/questions/2547817/what-is-the-difference-between... > > [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#... > > [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#... > > > > > > - marko > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org (mailto:aerogear-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/aerogear-dev