[aerogear-dev] TODO server app observations

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] TODO server app observations

Marko Strukelj

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] TODO server app observations

tech4j@gmail.com
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] TODO server app observations

Marko Strukelj
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
> > [hidden email]
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] TODO server app observations

Bruno Oliveira
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:


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]
[2]
[5]
[7]


- marko


_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list

_______________________________________________
aerogear-dev mailing list


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev