Thanks a lot, Martin. That's definitely useful to know, and, wow...
too much magic.
On Wed, Sep 10, 2008 at 2:23 PM, Martin Ellis <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 4:27 PM, Kris Nuttycombe
> <[EMAIL PROTECTED]> wrote:
>> The only question I have is thread safety - it doesn't
Thanks for pointing that out. I usually use JTA-enabled datasources so I
don't muck around with UserTransaction directly that much.
Derek
On Wed, Sep 10, 2008 at 2:23 PM, Martin Ellis <[EMAIL PROTECTED]> wrote:
>
> On Wed, Sep 10, 2008 at 4:27 PM, Kris Nuttycombe
> <[EMAIL PROTECTED]> wrote:
> >
On Wed, Sep 10, 2008 at 4:27 PM, Kris Nuttycombe
<[EMAIL PROTECTED]> wrote:
> The only question I have is thread safety - it doesn't seem
> like I should really be using a variable on the singleton to store the
> transaction; should I instead be creating a separate RequestVar to
> hold it?
It is
That possibility had occurred to me. Perhaps the best thing is just to
create a separate object for the persistence context that defines both
persistence & transaction operations. You'd then have implementations
for both JTA and RESOURCE_LOCAL type persistence units and store that
in the RequestVa
I'd be a little concerned about possible race conditions. I don't know
enough about the underlying handling of the RequestVar lifecycle, but I
wonder if the transaction RequestVar could get tossed before the EM
RequestVar (which calls closeEM). You might want to make it a pure
ThreadLocal to avoid
The getTransaction method on the EntityManager only works for
REQUEST_LOCAL persistence units, and throws an exception in a JTA
context.
Here's my ultimate solution (not yet tested for thread safety though)
object EM extends ScalaEntityManager() {
val context = new InitialContext()
private
I agree; I don't think you should be using the transaction in a global
object directly. Most of my experience with JPA has been with
container-managed JTA, so a lot of this isn't even needed. I'm a little
unfamiliar with the more manual management of the transaction. If I remember
correctly, the lo
Okay, I finally resolved the issue; it turned out to be my
unfamiliarity with JTA that was the primary problem. I hadn't realized
that in a servlet one needs to explicitly begin the JTA transaction.
Here's what my Model class looks like now:
import javax.naming.InitialContext
import javax.persist
You should be able to control the transaction handling in your
persistence.xml if you really want to. The transaction-type attribute on the
persistence-unit element can be used to choose whether you do your own
transactions (RESOURCE_LOCAL) or if it attempts to use JTA directly (JTA).
Of course, if
The principal reason I'm using Hibernate is because the base JPA
unfortunately doesn't provide support for non-standard type
persistence, and so a few of my entities are annotated with @Type in
order to use custom mappings for some of the org.joda.time classes
(the Order object in question being o
I'm pretty sure that the RequestVar should be around for the life of the
Lift session, which means that you should still have a valid lift session in
*any* snippet that would get called. Viktor's correct that this is a common
error that people run into with JPA, but it's usually because they're doi
> On Tue, Sep 9, 2008 at 10:09 AM, Oliver <[EMAIL PROTECTED]> wrote:
>>
>> Actually, is this the essence of the cookie. Why has the object been
>> detached in the example Kris gives - is there something wrong with
>> RequestVar lifecycle?
Right; sorry, I should have been more clear about my quest
On Tue, Sep 9, 2008 at 3:59 PM, Oliver Lambert <[EMAIL PROTECTED]> wrote:
> Now, now lets not get testi ;-)
>
*laugh*
It's chill ;)
Cheers,
>
> On 09/09/2008, at 9:34 PM, Viktor Klang wrote:
>
>
>
> On Tue, Sep 9, 2008 at 10:09 AM, Oliver <[EMAIL PROTECTED]> wrote:
>
>> Actually, is this the
Now, now lets not get testi ;-)
On 09/09/2008, at 9:34 PM, Viktor Klang wrote:
>
>
> On Tue, Sep 9, 2008 at 10:09 AM, Oliver <[EMAIL PROTECTED]> wrote:
> Actually, is this the essence of the cookie. Why has the object been
> detached in the example Kris gives - is there something wrong with
>
On Tue, Sep 9, 2008 at 10:09 AM, Oliver <[EMAIL PROTECTED]> wrote:
> Actually, is this the essence of the cookie. Why has the object been
> detached in the example Kris gives - is there something wrong with
> RequestVar lifecycle?
>
Actually, just add a simple debug-print when the session is crea
Actually, is this the essence of the cookie. Why has the object been
detached in the example Kris gives - is there something wrong with
RequestVar lifecycle?
On Tue, Sep 9, 2008 at 5:27 PM, Viktor Klang <[EMAIL PROTECTED]> wrote:
> Hello Kris,
>
> this is a quite common problem in the world of JP
Hello Kris,
this is a quite common problem in the world of JPA and object references.
I'm not going to bore people out by talking about object lifecycles, but
here's the essence of the cookie:
When a JPA Session is created, it is bound to some context (wether it be the
currently running thread, a
It looks a little like the RequestVar has had its lifecycle closing hook
called by the time you call getSubscriptions
Try touch/get the subscriptions before you pass them into the bind.
cheers
Oliver
On Tue, Sep 9, 2008 at 7:31 AM, Kris Nuttycombe
<[EMAIL PROTECTED]>wrote:
>
> I've been followin
18 matches
Mail list logo
