I'll answer these from a GS/J perspective:
> -----Original Message-----
> From: Kenneth D. Litwak [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, December 22, 1999 6:30 PM
> To: [EMAIL PROTECTED]
> Subject: Four EJB questions
>
> 1. Are there any tools to aid in debugging EJB code? SIne an EJB is
> pretty far
> removed from tier 1, where most IDEs focus, I'm not sure how you'd debug
> problems or code in an EJB.
>
GemStone/J provides a distributed debugging capability, so you can debug
server beans from your client. This includes source code based single
stepping, break points and the like.
> 2. Does the requirement for an Entity bean to hae a PrimaryKey mean that
> your
> database table has to have a matching primary key or can you define a
> primary
> key for the bean on any column? Thisis particularly an issue if the
> database is
> an OODBMS, which doesn't model data in columns.
>
I am not crystal clear on the first part of the question. An EntityBean
primary key can have multiple aspects (and map to multiple columns) if
that's what you are getting at. The data source you are mapping to must have
primary key (one or a combination of columns). There are probably triks to
get around this, but it is ill advised.
With regard to OODBMS, it is not clear IMHO whether Entity Beans add any
value. The Entity Bean wrapper adds a level of indirection that is only
slowing things down. That said, many want to stick to an EntityBean model
anyway, and in that case a PrimaryKey class is required. This is typically
not an issue if bean represent domain object graphs (instead of fine grained
objects). In this case it is usually natural for the root domain object to
have a key.
> 3. I've read that on the oone hand, Entity beans should not do transaction
> demarcation tyhemsevles but that on the other hand, a transaction ends
> when an
> entity bean's method ends, as opposed to a stateful session bean's method,
> which
> may return in the middle of a transaction. If the transaction must end at
> the
> endof the entity bean's mehtod, but the entity bean is not supposed to do
> its
> own transaction demarcation, there's a problem. I don't see how both of
> those
> could be tgrue at the same time.
>
I think there is a misunderstanding here. If a bean is invoked (entity or
session) and its transaction deployment indicates that a transaction is
required, then the transaction will complete if it was started for the bean.
If the transaction was in progress when the bean was invoked, it will
participate in the existing transaction, and the transaction is not
committed until we get to the top of the stack context that started the
transaction.
> 4. I'm reading contradictory things about JTS. One thing I read said that
> it
> implements OTS and is a competle transaction manager. Another thing I
> read said
> that it implements OTS and acts as a layer on top of a transaction
> manager, like
> Tuxedo. Which is it?
>
JTS is simply an interface. The underlying implementation may be CORBA OTS
or some other proprietary transaction manager. In the case of GemStone/J it
is CORBA OTS...
> Thanks.
>
>
> Ken
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
