Thanks, everyone. I definately have the SLSB facade. The SLSB is in charge 
of creating the EBs.

When you create the EB (or attempt to) and it throws a CreateException, how 
do you know if the exception is due to the key being taken or some other 
failure, such as disk full and such? Thats what I'm trying to figure out. 
If I can't know exactly what the failure is, I can't assume its caused by a 
non-unique key.

Thanks!

Jim

--On Friday, March 02, 2001 12:46 PM -0800 John Moore 
<[EMAIL PROTECTED]> wrote:

>
>
> I agree with Rick regarding the session bean facade.
>
> We choose to attempt the insert and handle the exception rather than do a
> findByPrimaryKey() for every inserted record.  Our belief is that there
> was no reason to fetch an existing entity when it represented something
> we didn't want.  Capturing the exception because of a duplicate key (and
> handing back the "user id taken" exception to the caller) was better than
> capturing the exception on a row not found and then trying the insert
> (which also might result in duplicate key 1 in a million but it could
> happen).
>
> Note that the above is not yet in production; so take the recommendation
> as such.  Open to comments and criticism.
>
> John More
>
>
> -----Original Message-----
> From: Hansen, Richard [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 02, 2001 12:26 PM
> To: 'JBoss-User'
> Subject: RE: [jBoss-User] Design question - Checking for an existing
> recor d??
>
> I think you need to think session bean facade. Have a session bean wrap
> user  the registration task. The session bean gets the user registration
> info,  checks the id for uniqueness using a SQL call, generates a "user
> id taken"  exception if not unique or else creates the user entity bean.
>
> Rick Hansen
>
>> -----Original Message-----
>> From: Jim Archer [mailto:[EMAIL PROTECTED]]
>> Sent: Friday, March 02, 2001 2:04 PM
>> To: JBoss-User
>> Subject: RE: [jBoss-User] Design question - Checking for an existing
>> recor d??
>>
>>
>> John, thanks for the reply...
>>
>> Why do you feel I need a unique key generator? I want the
>> userID to be the
>> key and I want it to be unique, and I want it to be user selected.
>>
>> If the user selects an id thats in use, they can pick another
>> and/or the
>> app can suggest one.
>>
>> My primary concern is knowing if the user selected ID is
>> already in use. Is
>> there a way I can use a unique key generator for that?
>>
>> Thanks...
>>
>> Jim
>>
>> --On Friday, March 02, 2001 11:55 AM -0800 John Moore
>> <[EMAIL PROTECTED]> wrote:
>>
>> >
>> >
>> > you need a unique key generator.  Check out
>> theserverside.com (patterns
>> > section) for discussion on ways to handle it.  JBoss used
>> to come with
>> > one but I don't see it any more.
>> >
>> >
>> > -----Original Message-----
>> > From: Jim Archer [mailto:[EMAIL PROTECTED]]
>> > Sent: Friday, March 02, 2001 11:45 AM
>> > To: JBoss-User
>> > Subject: [jBoss-User] Design question - Checking for an existing
>> > record??
>> >
>> > Hi All...
>> >
>> > I have what must be a fairly common problem and I was wondering if
>> > someone  could suggest what they think the preferred
>> solution might be.
>> >
>> > I need to create an EB for a user and I have set the userid up as a
>> > primary  jey. Of course, the user ID must be unique. I'm
>> wondering what
>> > the best way  to detect that a new user has picked an
>> unavailable user
>> > ID.
>> >
>> > First, I could just try to create the EB and catch a create
>> exception.
>> > The  downside to this seems to be that if I get a create exception I
>> > don't know  for sure it was created sue to a non-unique key
>> field without
>> > looking at  the message text that might vary accross
>> servers. So it seems
>> > that I can  only know that there was some problem.
>> >
>> > The next option is to use the finder for primary key and
>> see if I get a
>> > record back. This would answer the question but seems like
>> extra overhead
>> > to introduce. Also, it would result in a FinderException
>> when the userID
>> > is  unique and I don't know if that will roll back the
>> transaction I'm in
>> > or  not. Of course, I have to check for existance and add
>> the new one in
>> > the  same transaction.
>> >
>> > Is there a third option? I would appreciate any suggestions!
>> >
>> > Thanks lots!
>> >
>> > Jim
>> >
>> > ********************************************
>> > I shall be telling this with a sigh
>> > Somewhere ages and ages hence:
>> > Two roads diverged in a wood, and I -
>> > I took the one less traveled by,
>> > And that has made all the difference.
>> >
>> > - Robert Frost, 1916
>> >
>> >
>> > --
>> > --------------------------------------------------------------
>> > To subscribe:        [EMAIL PROTECTED]
>> > To unsubscribe:      [EMAIL PROTECTED]
>>
>>
>>
>> ********************************************
>> I shall be telling this with a sigh
>> Somewhere ages and ages hence:
>> Two roads diverged in a wood, and I -
>> I took the one less traveled by,
>> And that has made all the difference.
>>
>> - Robert Frost, 1916
>>
>>
>>
>> --
>> --------------------------------------------------------------
>> To subscribe:        [EMAIL PROTECTED]
>> To unsubscribe:      [EMAIL PROTECTED]
>>
>
> --
> --------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]



********************************************
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I -
I took the one less traveled by,
And that has made all the difference.

- Robert Frost, 1916



--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]

Reply via email to