2:36 p.m.
Hello everyone!
Checking out the CDI 1.0 spec and actually trying it on JBoss AS 7.1.0.Final it seems to
me that the Request Scope is not active in @Singleton @Startup @PostConstruct method, so
I'd like to propose this use case to be supported in the next version of CDI.
Moreover, quoting https://issues.jboss.org/browse/CDI-148 ("There is no reason why
the ConversationScope should be any less available than the RequestScope"), I think
that conversation scope should be available too in this context. It would be very useful,
for example, when you have an EntityManager produced in conversation scope (mostly used in
JSF contexts), to be allowed to use it @Singleton @Startup @PostConstruct methods.
Of course there should be some limitations in this case (long running conversation
promotion shouldn't be allowed for example), but the basic case should be supported in
my opinion.
Thanks for the attention,
Guido
10:30 a.m.
Please file a CDI issue :-)
On 2 Mar 2012, at 13:36, Guido Bonazza wrote:
Hello everyone!
Checking out the CDI 1.0 spec and actually trying it on JBoss AS 7.1.0.Final it seems to
me that the Request Scope is not active in @Singleton @Startup @PostConstruct method, so
I'd like to propose this use case to be supported in the next version of CDI.
Moreover, quoting https://issues.jboss.org/browse/CDI-148 ("There is no reason why
the ConversationScope should be any less available than the RequestScope"), I think
that conversation scope should be available too in this context. It would be very useful,
for example, when you have an EntityManager produced in conversation scope (mostly used in
JSF contexts), to be allowed to use it @Singleton @Startup @PostConstruct methods.
Of course there should be some limitations in this case (long running conversation
promotion shouldn't be allowed for example), but the basic case should be supported in
my opinion.
Thanks for the attention,
Guido
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
2:58 p.m.
Folks, again and again and again:
@ConversationScoped EntityManager is broken, broken, broken. The EM is per JPA spec NOT
Serializable and thus must not get stored in the Session.
There are some impls which _are_ Serializable, but those are not JPA spec compliant (e.g.
avajé eBean). With the mandatory support of locking and pessimistic locking it is just
technically impossible to implement a Serializable EntityManager.
> Moreover, quoting https://issues.jboss.org/browse/CDI-148
("There is
no reason why the ConversationScope should be any less available than the
RequestScope"),
Well, there is a difference between a Servlet-Request and a
JSF-Request. The difference is subtle but important. The JSF-Request is e.g _not_
available in some ServletFilters which are outside of the JSFs FacesServlet handling. The
CDI spec states this in 6.7.4:
If the conversation associated with the current JSF request is in the
transient state at the end of a JSF request,
it is destroyed, and the conversation context is also destroyed.
But the Request Context lives much longer! It will also be available in various
ServletFilters and Listeners. Thus the statement is not entirely correct.
to be allowed to use it @Singleton @Startup @PostConstruct methods.
Of which Beans are you talking here? EJBs? CDI managed beans? Which @Singleton
annotation? the one from JSR-330 or EJB?
Please also note that the JSR-330 @Singleton is imo completely useless because it's
underspecified. "Singleton" in which _context_?
1 per WebApp?
1 per EAR?
1 per JVM?
1 per Cluster?
LieGrue,
strub
----- Original Message -----
From: Pete Muir <pmuir(a)redhat.com>
To: Guido Bonazza <guidbona(a)yahoo.com>
Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
Sent: Tuesday, March 6, 2012 10:30 AM
Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton @Startup
@PostConstruct methods
Please file a CDI issue :-)
On 2 Mar 2012, at 13:36, Guido Bonazza wrote:
> Hello everyone!
> Checking out the CDI 1.0 spec and actually trying it on JBoss AS
7.1.0.Final it seems to me that the Request Scope is not active in @Singleton
@Startup @PostConstruct method, so I'd like to propose this use case to be
supported in the next version of CDI.
> Moreover, quoting https://issues.jboss.org/browse/CDI-148 ("There is
no reason why the ConversationScope should be any less available than the
RequestScope"), I think that conversation scope should be available too in
this context. It would be very useful, for example, when you have an
EntityManager produced in conversation scope (mostly used in JSF contexts), to
be allowed to use it @Singleton @Startup @PostConstruct methods.
> Of course there should be some limitations in this case (long running
conversation promotion shouldn't be allowed for example), but the basic case
should be supported in my opinion.
>
> Thanks for the attention,
> Guido
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
5:38 p.m.
On 6 Mar 2012, at 13:58, Mark Struberg wrote:
Folks, again and again and again:
@ConversationScoped EntityManager is broken, broken, broken. The EM is per JPA spec NOT
Serializable and thus must not get stored in the Session.
There are some impls which _are_ Serializable, but those are not JPA spec compliant (e.g.
avajé eBean). With the mandatory support of locking and pessimistic locking it is just
technically impossible to implement a Serializable EntityManager.
You can make this work (Seam 2 kinda did it with the Hibernate and a lot of code to deal
with entities being properly propagated - basically imposing serialisation above the JVM
layer) and I know the JBoss Clustering team are looking at this. But it is a vendor
specific solution only.
>> Moreover, quoting https://issues.jboss.org/browse/CDI-148 ("There is
> no reason why the ConversationScope should be any less available than the
> RequestScope"),
Well, there is a difference between a Servlet-Request and a JSF-Request. The difference
is subtle but important. The JSF-Request is e.g _not_ available in some ServletFilters
which are outside of the JSFs FacesServlet handling. The CDI spec states this in 6.7.4:
> If the conversation associated with the current JSF request is in the transient state
at the end of a JSF request,
> it is destroyed, and the conversation context is also destroyed.
But the Request Context lives much longer! It will also be available in various
ServletFilters and Listeners. Thus the statement is not entirely correct.
I think the statement is one of intent, not state. I.e. there is no reason it should be
less available.
> to be allowed to use it @Singleton @Startup @PostConstruct methods.
Of which Beans are you talking here? EJBs? CDI managed beans? Which @Singleton
annotation? the one from JSR-330 or EJB?
Please also note that the JSR-330 @Singleton is imo completely useless because it's
underspecified. "Singleton" in which _context_?
1 per WebApp?
1 per EAR?
1 per JVM?
1 per Cluster?
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir(a)redhat.com>
> To: Guido Bonazza <guidbona(a)yahoo.com>
> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 10:30 AM
> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton
@Startup @PostConstruct methods
>
> Please file a CDI issue :-)
>
> On 2 Mar 2012, at 13:36, Guido Bonazza wrote:
>
>> Hello everyone!
>> Checking out the CDI 1.0 spec and actually trying it on JBoss AS
> 7.1.0.Final it seems to me that the Request Scope is not active in @Singleton
> @Startup @PostConstruct method, so I'd like to propose this use case to be
> supported in the next version of CDI.
>> Moreover, quoting https://issues.jboss.org/browse/CDI-148 ("There is
> no reason why the ConversationScope should be any less available than the
> RequestScope"), I think that conversation scope should be available too in
> this context. It would be very useful, for example, when you have an
> EntityManager produced in conversation scope (mostly used in JSF contexts), to
> be allowed to use it @Singleton @Startup @PostConstruct methods.
>> Of course there should be some limitations in this case (long running
> conversation promotion shouldn't be allowed for example), but the basic case
> should be supported in my opinion.
>>
>> Thanks for the attention,
>> Guido
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
6:27 p.m.
> @ConversationScoped EntityManager is broken, broken, broken. The
EM is per
JPA spec NOT Serializable and thus must not get stored in the Session.
> There are some impls which _are_ Serializable, but those are not JPA spec
compliant (e.g. avajé eBean). With the mandatory support of locking and
pessimistic locking it is just technically impossible to implement a
Serializable EntityManager.
You can make this work (Seam 2 kinda did it with the Hibernate and a lot of code
to deal with entities being properly propagated - basically imposing
serialisation above the JVM layer) and I know the JBoss Clustering team are
looking at this. But it is a vendor specific solution only.
Well, I know that there is some Hibernate mode which supports some serialization but in
this mode
.) it is not JPA compliant anymore
.) you will loose the 'state' of the entities after the serialisation
.) this was only JPA1
.) you will loose all pessimistic locks
.) it's not portable
I still think that detaching after each request and merging it the next time works best
for an EE 6 app.
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: Guido Bonazza <guidbona(a)yahoo.com>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 5:38 PM
> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton
@Startup @PostConstruct methods
>
>
> On 6 Mar 2012, at 13:58, Mark Struberg wrote:
>
>>
>>
>> Folks, again and again and again:
>>
>>
> @ConversationScoped EntityManager is broken, broken, broken. The
EM is per
JPA spec NOT Serializable and thus must not get stored in the Session.
> There are some impls which _are_ Serializable, but those are not JPA spec
compliant (e.g. avajé eBean). With the mandatory support of locking and
pessimistic locking it is just technically impossible to implement a
Serializable EntityManager.
You can make this work (Seam 2 kinda did it with the Hibernate and a lot of code
to deal with entities being properly propagated - basically imposing
serialisation above the JVM layer) and I know the JBoss Clustering team are
looking at this. But it is a vendor specific solution only.
>>
>>
>>
>>>> Moreover, quoting https://issues.jboss.org/browse/CDI-148
> ("There is
>>> no reason why the ConversationScope should be any less available than
> the
>>> RequestScope"),
>> Well, there is a difference between a Servlet-Request and a JSF-Request.
> The difference is subtle but important. The JSF-Request is e.g _not_ available
> in some ServletFilters which are outside of the JSFs FacesServlet handling. The
> CDI spec states this in 6.7.4:
>>
>>> If the conversation associated with the current JSF request is in the
> transient state at the end of a JSF request,
>>> it is destroyed, and the conversation context is also destroyed.
>>
>> But the Request Context lives much longer! It will also be available in
> various ServletFilters and Listeners. Thus the statement is not entirely
> correct.
>
> I think the statement is one of intent, not state. I.e. there is no reason it
> should be less available.
>
>>
>>
>>> to be allowed to use it @Singleton @Startup @PostConstruct methods.
>> Of which Beans are you talking here? EJBs? CDI managed beans? Which
> @Singleton annotation? the one from JSR-330 or EJB?
>>
>> Please also note that the JSR-330 @Singleton is imo completely useless
> because it's underspecified. "Singleton" in which _context_?
>>
>> 1 per WebApp?
>>
>> 1 per EAR?
>> 1 per JVM?
>> 1 per Cluster?
>>
>>
>> LieGrue,
>> strub
>>
>> ----- Original Message -----
>>> From: Pete Muir <pmuir(a)redhat.com>
>>> To: Guido Bonazza <guidbona(a)yahoo.com>
>>> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>> Sent: Tuesday, March 6, 2012 10:30 AM
>>> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in
> @Singleton @Startup @PostConstruct methods
>>>
>>> Please file a CDI issue :-)
>>>
>>> On 2 Mar 2012, at 13:36, Guido Bonazza wrote:
>>>
>>>> Hello everyone!
>>>> Checking out the CDI 1.0 spec and actually trying it on JBoss AS
>>> 7.1.0.Final it seems to me that the Request Scope is not active in
> @Singleton
>>> @Startup @PostConstruct method, so I'd like to propose this use
> case to be
>>> supported in the next version of CDI.
>>>> Moreover, quoting https://issues.jboss.org/browse/CDI-148
> ("There is
>>> no reason why the ConversationScope should be any less available than
> the
>>> RequestScope"), I think that conversation scope should be
> available too in
>>> this context. It would be very useful, for example, when you have an
>>> EntityManager produced in conversation scope (mostly used in JSF
> contexts), to
>>> be allowed to use it @Singleton @Startup @PostConstruct methods.
>>>> Of course there should be some limitations in this case (long
> running
>>> conversation promotion shouldn't be allowed for example), but the
> basic case
>>> should be supported in my opinion.
>>>>
>>>> Thanks for the attention,
>>>> Guido
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
6:30 p.m.
I'm not necessarily disagreeing with you ;-)
On 7 Mar 2012, at 17:27, Mark Struberg wrote:
>> @ConversationScoped EntityManager is broken, broken, broken.
The EM is per
> JPA spec NOT Serializable and thus must not get stored in the Session.
>> There are some impls which _are_ Serializable, but those are not JPA spec
> compliant (e.g. avajé eBean). With the mandatory support of locking and
> pessimistic locking it is just technically impossible to implement a
> Serializable EntityManager.
>
> You can make this work (Seam 2 kinda did it with the Hibernate and a lot of code
> to deal with entities being properly propagated - basically imposing
> serialisation above the JVM layer) and I know the JBoss Clustering team are
> looking at this. But it is a vendor specific solution only.
>
Well, I know that there is some Hibernate mode which supports some serialization but in
this mode
.) it is not JPA compliant anymore
.) you will loose the 'state' of the entities after the serialisation
.) this was only JPA1
.) you will loose all pessimistic locks
.) it's not portable
I still think that detaching after each request and merging it the next time works best
for an EE 6 app.
LieGrue,
strub
----- Original Message -----
> From: Pete Muir <pmuir(a)redhat.com>
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: Guido Bonazza <guidbona(a)yahoo.com>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)lists.jboss.org>
> Sent: Tuesday, March 6, 2012 5:38 PM
> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton
@Startup @PostConstruct methods
>
>
> On 6 Mar 2012, at 13:58, Mark Struberg wrote:
>
>>
>>
>> Folks, again and again and again:
>>
>>
>> @ConversationScoped EntityManager is broken, broken, broken. The EM is per
> JPA spec NOT Serializable and thus must not get stored in the Session.
>> There are some impls which _are_ Serializable, but those are not JPA spec
> compliant (e.g. avajé eBean). With the mandatory support of locking and
> pessimistic locking it is just technically impossible to implement a
> Serializable EntityManager.
>
> You can make this work (Seam 2 kinda did it with the Hibernate and a lot of code
> to deal with entities being properly propagated - basically imposing
> serialisation above the JVM layer) and I know the JBoss Clustering team are
> looking at this. But it is a vendor specific solution only.
>
>>
>>
>>
>>>> Moreover, quoting https://issues.jboss.org/browse/CDI-148
> ("There is
>>> no reason why the ConversationScope should be any less available than
> the
>>> RequestScope"),
>> Well, there is a difference between a Servlet-Request and a JSF-Request.
> The difference is subtle but important. The JSF-Request is e.g _not_ available
> in some ServletFilters which are outside of the JSFs FacesServlet handling. The
> CDI spec states this in 6.7.4:
>>
>>> If the conversation associated with the current JSF request is in the
> transient state at the end of a JSF request,
>>> it is destroyed, and the conversation context is also destroyed.
>>
>> But the Request Context lives much longer! It will also be available in
> various ServletFilters and Listeners. Thus the statement is not entirely
> correct.
>
> I think the statement is one of intent, not state. I.e. there is no reason it
> should be less available.
>
>>
>>
>>> to be allowed to use it @Singleton @Startup @PostConstruct methods.
>> Of which Beans are you talking here? EJBs? CDI managed beans? Which
> @Singleton annotation? the one from JSR-330 or EJB?
>>
>> Please also note that the JSR-330 @Singleton is imo completely useless
> because it's underspecified. "Singleton" in which _context_?
>>
>> 1 per WebApp?
>>
>> 1 per EAR?
>> 1 per JVM?
>> 1 per Cluster?
>>
>>
>> LieGrue,
>> strub
>>
>> ----- Original Message -----
>>> From: Pete Muir <pmuir(a)redhat.com>
>>> To: Guido Bonazza <guidbona(a)yahoo.com>
>>> Cc: "cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
>>> Sent: Tuesday, March 6, 2012 10:30 AM
>>> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in
> @Singleton @Startup @PostConstruct methods
>>>
>>> Please file a CDI issue :-)
>>>
>>> On 2 Mar 2012, at 13:36, Guido Bonazza wrote:
>>>
>>>> Hello everyone!
>>>> Checking out the CDI 1.0 spec and actually trying it on JBoss AS
>>> 7.1.0.Final it seems to me that the Request Scope is not active in
> @Singleton
>>> @Startup @PostConstruct method, so I'd like to propose this use
> case to be
>>> supported in the next version of CDI.
>>>> Moreover, quoting https://issues.jboss.org/browse/CDI-148
> ("There is
>>> no reason why the ConversationScope should be any less available than
> the
>>> RequestScope"), I think that conversation scope should be
> available too in
>>> this context. It would be very useful, for example, when you have an
>>> EntityManager produced in conversation scope (mostly used in JSF
> contexts), to
>>> be allowed to use it @Singleton @Startup @PostConstruct methods.
>>>> Of course there should be some limitations in this case (long
> running
>>> conversation promotion shouldn't be allowed for example), but the
> basic case
>>> should be supported in my opinion.
>>>>
>>>> Thanks for the attention,
>>>> Guido
>>>>
>>>> _______________________________________________
>>>> cdi-dev mailing list
>>>> cdi-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
12:26 p.m.
Simply as that: as the EntityManager per spec doesn't implement Serializable.
Also the EJB spec explicitely states it as well in Section 4.2:
- A container must not passivate a stateful session bean with an
extended
persistence context unless ...
Thus an Extended EM doesn't need to be Serializable. If you build a feature based on
the assumption that each EntityManager is Serializable, then it will result in
non-portable behaviour.
Well, in JPA-1 it would at least have been possible to implement a Serializable EM, but in
JPA2 you are mostly out of luck.
There are tons of indicators. As an example: how would you serialize an EntityManager
which holds a pessimistic lock() on the database? ^^
LieGrue,
strub
----- Original Message -----
From: Christian Bauer <christian.bauer(a)gmail.com>
To: cdi-dev(a)lists.jboss.org
Cc:
Sent: Thursday, March 15, 2012 9:18 AM
Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton @Startup
@PostConstruct methods
On Mar 6, 2012, at 2:58 , Mark Struberg wrote:
> The EM is per JPA spec NOT Serializable and thus must not get stored in the
Session.
Chapter and section?
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
12:34 p.m.
On 15/03/2012, at 10:26 PM, Mark Struberg wrote:
Simply as that: as the EntityManager per spec doesn't implement
Serializable.
Also the EJB spec explicitely states it as well in Section 4.2:
> - A container must not passivate a stateful session bean with an extended
> persistence context unless ...
Thus an Extended EM doesn't need to be Serializable. If you build a feature based on
the assumption that each EntityManager is Serializable, then it will result in
non-portable behaviour.
Well, in JPA-1 it would at least have been possible to implement a Serializable EM, but
in JPA2 you are mostly out of luck.
There are tons of indicators. As an example: how would you serialize an EntityManager
which holds a pessimistic lock() on the database? ^^
If you are holding a lock longer that a request you are doing something wrong. As you are
probably not going to want to serialise the entity manager in the middle of a request it
should be possible to work around it.
Also not everyone uses HA clusters or persistent sessions, so the conversation scope is
not always actually serialised.
There are still a lot of use cases for this, but it obviously there are limitations.
Stuart
LieGrue,
strub
----- Original Message -----
> From: Christian Bauer <christian.bauer(a)gmail.com>
> To: cdi-dev(a)lists.jboss.org
> Cc:
> Sent: Thursday, March 15, 2012 9:18 AM
> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton
@Startup @PostConstruct methods
>
>
> On Mar 6, 2012, at 2:58 , Mark Struberg wrote:
>
>> The EM is per JPA spec NOT Serializable and thus must not get stored in the
> Session.
>
> Chapter and section?
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev
3:40 p.m.
Stu,
usually a select for update is done _explicitely_ to prevent others from doing something
with this entity. We do not have control whether this is good or not.
I do agree with you that this should barely be used in a webapp, because sometimes this
can even lead to a table-lock (some dbs cannot do a simple record lock without either
locking the page or sometimes even the whole table).
Imo this functionality should NEVER have added to the EntityManager but might have been
provided via a separate API, etc. But that's how it is currently :/
But this is not the only reason why the EM is not Serializable. If you did serialize an
old Hibernate-2 EM then you lost all the non-persistent status. This doesn't sound
sane neither...
LieGrue,
strub
----- Original Message -----
From: Stuart Douglas <stuart.w.douglas(a)gmail.com>
To: Mark Struberg <struberg(a)yahoo.de>
Cc: Christian Bauer <christian.bauer(a)gmail.com>;
"cdi-dev(a)lists.jboss.org" <cdi-dev(a)lists.jboss.org>
Sent: Thursday, March 15, 2012 12:34 PM
Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in @Singleton @Startup
@PostConstruct methods
On 15/03/2012, at 10:26 PM, Mark Struberg wrote:
> Simply as that: as the EntityManager per spec doesn't implement
Serializable.
>
>
> Also the EJB spec explicitely states it as well in Section 4.2:
>> - A container must not passivate a stateful session bean with an
extended
>> persistence context unless ...
>
>
> Thus an Extended EM doesn't need to be Serializable. If you build a
feature based on the assumption that each EntityManager is Serializable, then it
will result in non-portable behaviour.
>
> Well, in JPA-1 it would at least have been possible to implement a
Serializable EM, but in JPA2 you are mostly out of luck.
>
> There are tons of indicators. As an example: how would you serialize an
EntityManager which holds a pessimistic lock() on the database? ^^
If you are holding a lock longer that a request you are doing something wrong.
As you are probably not going to want to serialise the entity manager in the
middle of a request it should be possible to work around it.
Also not everyone uses HA clusters or persistent sessions, so the conversation
scope is not always actually serialised.
There are still a lot of use cases for this, but it obviously there are
limitations.
Stuart
>
> LieGrue,
> strub
>
>
>
>
> ----- Original Message -----
>> From: Christian Bauer <christian.bauer(a)gmail.com>
>> To: cdi-dev(a)lists.jboss.org
>> Cc:
>> Sent: Thursday, March 15, 2012 9:18 AM
>> Subject: Re: [cdi-dev] Support Request (and Conversation?) Scope in
@Singleton @Startup @PostConstruct methods
>>
>>
>> On Mar 6, 2012, at 2:58 , Mark Struberg wrote:
>>
>>> The EM is per JPA spec NOT Serializable and thus must not get
stored in the
>> Session.
>>
>> Chapter and section?
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
4676
days inactive
4689
days old
9 comments
5 participants
participants (5)
-
Christian Bauer -
Guido Bonazza -
Mark Struberg -
Pete Muir -
Stuart Douglas