If you can't get SQL Server's autonumber to work, you can make a
PrimaryKeyBean which issues unique primary keys for your different beans.
Its attributes would be the last issued key for each table/bean which needs
a unique id.
----- Original Message -----
From: "Lau Chet Hong" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 13, 2001 10:46 PM
Subject: [JBoss-user] How to use uniqueidentifier / auto-numbering field in
a database ?
> 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
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
