Dear all,
Does jBoss supports those called uniqueidentifier / auto-number field type
in a database ? I am trying to use a primary key field with uniqueidentifier
type in SQL Server 2000, but couldn't manage. How should I configure my
jaws.xml and my source code to use it ? Thank you very much!
Regards,
ChetHong Lau
> -----Original Message-----
> From: Georg Rehfeld [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 14, 2001 11:20 AM
> To: [EMAIL PROTECTED]
> Subject: Re: More Re: [JBoss-user] When do entity beans commit?
>
>
> Dear Bryan,
>
> > 6. Log messages from server.log - yes this message seemed to
> > appear many hundred times in a row, around the time of my
> > deadlock:
> >
> > [staffBean] LOCKING-WAITING (TRANSACTION) for id
> com.theApp.ejb.staffPK@73
> > ctx.hash 2702560 tx:TransactionImpl:XidImpl
> > [FormatId=257, GlobalId=app-web1//188, BranchQual=]
>
> This clearly indicates access to an instance INSIDE a transaction
> that already is associated to another TX. Interesting would be to
> know if only staffBean with PK 73 is logged, or if other beans
> are involved/logged, and then which Transaction Global Id is
> shown there.
>
> In a true deadlock scenario you should see one instance logged
> with (in your case) 73 + app-web1//188 and at least one other
> with some other PK and Global Id (say 42 + app-web1//4711), in
> your case I expect both of type staffBean, but in complexer
> scenarios it could be of some other type. And the true deadlock
> case could even involve more beans cyclic waiting for each other.
>
> If you only see 73 + app-web1//188 LOCKING-WAITING it's more
> likely, that the instance is participating in a lengthy
> processing, so that TX app-web1//188 finally gives up, although
> now true deadlock condition exists.
>
> But having said all this, you told us, that the sessions method
> is 'Never' and the entity methods called are 'Supports', so you
> are right, there should be no transaction at all. And I assume,
> that, while your tests were running no intentional transactional
> methods were invoked?
>
> The last idea I can come up with is: might be you have a typo in
> your deployment descriptor where you try to set your methods to
> 'Supports' and thus they are left to the default 'Required'?
> Checked the CaSe too? I don't know, if this really is verified at
> deployment time.
>
> If this even isn't the case, I would report this as a possible
> bug at SourceForge, as nobody else came into this thread of
> discussion to help us. Best you would provide more complete
> server.log and your relevant deployment descriptor parts and code
> samples (i.e. for others to have a true look at case and names of
> methods etc.)
>
> Ah, and a final note: the code around the LOCKING-WAITING and the
> Exception you receive was just reworked to solve some other
> problem. The modifying author (Bill Burke) said, this only is a
> partial attempt at the LOCKING-WAITING (he was focused on the
> other problem, which he solved) issue, but the JBoss founder Marc
> Fleury is just about to rework that code even more.
>
> This modification(s) do nothing about the fact, that you see
> transactional behaviour, where it shouldn't be (IMHO), but if the
> above guess doesn't hold, you still may want to try the new
> version out. It's only checked into CVS, so you had to compile
> JBoss yourself for a test.
>
>
> > 4. Yes, conceivably some of the same entity beans are wanted by
> > other threads at the same time as this thread is doing it's
> > thing. However I thought that, being non-transactional, there
> > wouldn't be any contention problems. Maybe the calls are
> > serialized, but at least there wouldn't be any deadlocks. Am I
> > wrong?
>
> As far as I understand the code version you are executing (2.2.1
> or 2.2.2 I assume, did you tell us?) there could be deadlock with
> non-reentrant beans, at least when they actually do a callback
> (which would require reentrant to be enabled), but this would be
> logged differently, so in your case it doesn't seem to be the
> reason.
>
> Just to clarify (my favorite Sequence diagram again :-)
>
> session entity A entity B
> ------- -------- --------
> I mA1 | |
> I---------->I mB1 |
> I I---------->I
> I I I
> I I mA2 I
> I II<---------I <<< blocks forever
>
>
> This is due to a bug (I think) in JBoss in an attempt to be more
> wise than the EJB Spec, which requires an EJBException to be
> thrown when B calls back A via mA2 while A still is not finished
> with mA1 and the bean A isn't reentrant. JBoss instead would go
> into a busy waiting loop for mA1 to finish, which doesn't happen.
>
> But I'm not really sure on this, just haven't the old code
> around, and, oops, it's already again 5 a'clock in the morning,
> much too late to check the old source out and try to verify or do
> a test case now. If I turn out to be right, I SHOULD report that
> as a bug (that code in EntityInstanceInterceptor is really too
> tricky to fiddle with, when unexperienced)!
>
> best regards
> Georg
> ___ ___
> | + | |__ Georg Rehfeld Woltmanstr. 12 20097 Hamburg
> |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10
>
> PS: Bryan, could you please switch to ASCII instead of HTML, it's
> preferred/required on this list and by me too.
>
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
