JDO is a (soon-to-be? Java Community Process? standard) API for OR mapping
tools.
----- Original Message -----
From: "Jonathan Carlson" <[EMAIL PROTECTED]>
To: "'jBoss'" <[EMAIL PROTECTED]>
Sent: Friday, October 13, 2000 5:26 PM
Subject: RE: [jBoss-User] Is EJB the model for us ?
> I haven't used Castor or any other JDO tool, so I wouldn't be able to tell
> you the differences. The jRelationalFramework generates SQL to read and
> update objects. I'll have to look into Castor a little more.
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Natraj Gujran
> Sent: Friday, October 13, 2000 4:18 PM
> To: jBoss
> Subject: RE: [jBoss-User] Is EJB the model for us ?
>
>
> Thanks for the reply, Jonathan.
> So I guess our understanding was right about the Entity Beans. We have to
> stay away from CMP.
>
> Also, how is this SQL framework different from JDO/Castor ?
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Jonathan Carlson
> Sent: Friday, October 13, 2000 11:34 AM
> To: 'jBoss'
> Subject: RE: [jBoss-User] Is EJB the model for us ?
>
>
> I wouldn't recommend accessing your entity beans directly from the client.
> In fact, I wouldn't even recommend using entity beans.
>
> We ended up passing data objects to/from session beans which stored or
> retrieved the data using a SQL framework (which we have open-sourced at
> http://jrf.sourceforge.net) The performance gains by using this instead
of
> container-managed entity beans were incredible and the framework allowed
us
> to get a lot of code reuse.
>
> What we gained was transactions, security, and the value of keeping the
> database access logic on the server.
>
> Good Luck!
>
> Jonathan Carlson
> [EMAIL PROTECTED]
>
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Natraj Gujran
> > Sent: Friday, October 13, 2000 1:25 PM
> > To: [EMAIL PROTECTED]
> > Subject: [jBoss-User] Is EJB the model for us ?
> >
> >
> The scenario we have:
> We will have multiple JVMs running across the internet, that will access
> some EntityBean objects. For eg: CustomerAccount.
>
> The interactions:
> The interactions maybe occasionally write. But a large part will be read
> operations. Like 'getName()' , getCompanyName, getAddress .. and stuff
like
> that.
>
> Problems:
> Using the EJB model, if we have a CustomerAccount EntityBean, every method
> invocation on that bean from a different JVM will be over RMI. Now that
> will be a lot of traffic, and very slow. We accept the slowness when we
have
> to make updates/write operations into the object, but not for the hundreds
> of 'query/get' like methods.
>
> To solve this, we'll ultimately have to implement some interface to the
> EntityBean that will be a bunch of all the 'get/query' methods of the
> EntityBean, and send the interface & the relevant
> data copy down to the remote client. That way, we can prevent all the RMI
> invocations.
>
> But doing this, we've essentially overridden the good things in EJB, and
end
> up reinventing stuff.
> So, my question to you EJB experts is :
> Is our understanding of EJB/ RMI - as described in the argument above ,
> flawed ?
>
> How do we solve our problem, and still use all the good things offered by
an
> EJB container like persistence, scalability , Object querying, naming
> integration, etc.
>
> Thanks in advance,
> Natraj
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
>
>
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
