Entity bean design

Hello,
I have an existent application that use database view (very complex) to retrieve and display values from some tables.
I have to reproduce the same thing with EJB3 in a web application.
What is for you the best way to design entities beans ?

Similar Messages

[EJB3 - ADF Faces] entity bean design

Hello,
I have an existant application that use database view (very complex) to retrieve and display values from some tables.
I have to reproduce the same thing with EJB3 ans ADF Faces in a web application.
What is for you the best way to design entities beans ?
1. Create some buisness objects (entity beans) and feed them with a query thru the database view ?
2. Create a unique entity bean with only attributes who are used by the db view ?
In this case, the entity bean will be used only for this query.
3. ?
I think the best solution is the first one.
But in this case, how to display the result of the query in an ADF Faces table?
With the 2nd solution the query returns a list of object which will be used by the adf table. That would be much easier.
Thanks for your help.

The popup dialog is used for looking up a value of fields on the form. I have fields "location id" and "sub location id", the popup has cascading drop down lists where I choose which ones I want, then return those values from the popup and display the selection in readonly text inputs. Other inputs also exist on the form. Together they all make the input parameters to the session facade's query.

Unable to use Class Designer when deriving Entity Bean from another class

I have several Entity Beans that have common fields. In order to maximise reusability, I have defined a base class which contains these common fields and corresponding get/set methods on these fields.
In the next step, I build an Entity Bean using JDeveloper. I then go to Source Editor and in the Bean class, modify the Java code to inherit from this base class that I have defined. I then try to go to Class Designer expecting to see the inherited fields as well.
However, this is the error I get :
"Error while trying to parse source file...."
Any pointers on resolving this would be a great help ! Thanks !!!
-Andre
null

If you're running >Java 1.4, you'll need to put your classes into a package since Tomcat can no longer import the class 'BeanProdess' which is in an unnamed namespace.
Your JSP is compiled into a class (in the package org.apache.jsp) that doesn't recognize anything in the default package.
Here's a reference if you want to read about this.
http://java.sun.com/j2se/1.4/compatibility.html#incompatibilities1.4

Problem with 1-to-many relationship between entity beans

Hi All!
I have two tables TMP_GROUP and TMP_EMPLOYEE with following fields:
TMP_GROUP: ID, CAPTION, COMMENT, STATUS.
TMP_EMPLOYEE: ID, LOGIN, GROUP_ID.
For this tables i create two entity beans GROUP and EMPLOYEE respectively.
The relationship looks like this
descriptor ejb.xml:
<ejb-relation>
            <description>description</description>
            <ejb-relation-name>employeesOfGroup</ejb-relation-name>
            <ejb-relationship-role>
                <ejb-relationship-role-name>com.mypackage.GroupBean</ejb-relationship-role-name>
                <multiplicity>One</multiplicity>
                <relationship-role-source>
                    <ejb-name>GroupBean</ejb-name>
                </relationship-role-source>
                <cmr-field>
                    <cmr-field-name>employees</cmr-field-name>
                    <cmr-field-type>java.util.Collection</cmr-field-type>
                </cmr-field>
            </ejb-relationship-role>
            <ejb-relationship-role>
                <ejb-relationship-role-name>com.mypackage.EmployeeBean</ejb-relationship-role-name>
                <multiplicity>Many</multiplicity>
                <relationship-role-source>
                    <ejb-name>EmployeeBean</ejb-name>
                </relationship-role-source>
            </ejb-relationship-role>
        </ejb-relation>
descriptor persistent.xml:
<table-relation>
               <table-relationship-role
                    key-type="PrimaryKey">
                    <ejb-name>GroupBean</ejb-name>
                    <cmr-field>employees</cmr-field>
               </table-relationship-role>
               <table-relationship-role
                    key-type="NoKey">
                    <ejb-name>EmployeeBean</ejb-name>
                    <fk-column>
                         <column-name>GROUP_ID</column-name>
                         <pk-field-name>ejb_pk</pk-field-name>
                    </fk-column>
               </table-relationship-role>
          </table-relation>
Now i implement business method:
public Long addEmployee(String login, long groupId) {
          Long result;
          try {
               EmployeeLocal employee = employeeHome.create(login);
               GroupLocal group =
                    groupHome.findByPrimaryKey(new Long(groupId));
               Collection employees = group.getEmployees();
               employees.add(employee);
               result = (Long) employee.getPrimaryKey();
          } catch (CreateException ex) {
               result = new Long(0);
          } catch (FinderException ex) {
               result = new Long(0);
          return result;
When i call this method from web service, the following exception is raised:
com.sap.engine.services.ejb.exceptions.BaseTransactionRolledbackLocalException: Exception in method com.mypackage.GroupLocalHomeImpl0.findByPrimaryKey(java.lang.Object).
P.S.
1) I have transaction attribute set to "Required" for all methods of all beans
2) I have unique index for each table:
TMP_GROUP_I1: CAPTION
TMP_EMPLOYEE_I1: LOGIN (however i think GROUP_ID must be added here too)
3) I tried many:many relationship with this tables and it works fine
4) I try another implementation of addEmployee method with
EmployeeLocal employee = employeeHome.create(login, groupId);
without using GroupLocal cmr-field and GroupLocalHome findByPrimaryKey method, the result is same error.
Can somebody help me with this problem?
Thanks in advance.
Best regards, Abramov Andrey.

gimbal2 wrote:
1: The @JoinColumn on the listOfDepartments collection in Company is wrong. It should be something like this for a bidirectional relationship:
@OneToMany(mappedBy="company") // company is the matching property name in Department
private List <Department> listOfDepartment = new ArrayList<Department>();Note that I removed the fetch configuration; onetomany is fetched lazy by design. Saves some clutter eh.
2: use a Set in stead of a List (hibernate doesn't like lists much in entities and will break when you create slightly more complex entity relations)
3: don't just slap cascades on collections, especially of type ALL. Do it with care. In the many years I've been using JPA I've only had to cascade deletes in very specific situations, maybe once or twice. I never needed any of the other cascade types, they just invite sloppy code if you ask me. When working with persistence you should apply a little precision.I made all changes as you mentioned but still compID in department table shows null value...

Multiple instances of the same entity bean?

I am designing a J2EE application that is made up of a number of separate components that each have a well-defined responsibility. Each component is made up of one or more J2EE components (web clients and EJBs). I want to design the application such that it is easy in the future to deploy each component (or a group of components) on different servers. In order to do this I need to make sure that the interfaces between each component are exposed as remote interfaces (but I will use local interfaces inside each component). However, there are a number of entity beans that need to be accessed by more than one component. I am wondering how best to expose these entity beans. I believe there are a number of options:
1. Expose remote interfaces on each of the shared entity beans. The disadvantage of this approach is that it is inefficient and that I will not be able to take advantage of container managed relationships. (I am intending to use container managed persistence.)
2. Create a facade object (stateful session bean) for each of the entity beans which exposes a remote interface and in turn accesses the shared entity beans locally. The disadvantage of this approach is that I have to create some extra EJBs and that I cannot directly make use of container managed relationships etc from the client component.
3. I don't know if this is an option but I am wondering whether I can deploy a copy of each shared entity bean with each application component. The advantage of this approach is that the component would access the entity locally and could make use of container managed relationships. However, I don't know what the issues are with having more than one instance (per primary-key) of an entity in the same application. I don't know whether this would cause errors of whether they would get out of sync (because different instances with the same primary key would be updated by different clients). Initially each component would be deployed in the same server but later they would be deployed in different servers. In both cases with this option each component (JAR) would have copies of the shared entity bean classes.
Any suggestions as to the best approach and whether the last option is feasible would be much appreciated.
Thanks.

I think 2 beats 1. The main reason being to minimise the number of network calls. You're basically asking, are fascades a good idea? and the answer is yes.
You can obviously do 3 in different app servers. However you'll need to configure your app servers so they can handle the fact that they're not the only ones updating the database. This is to handle concurrency as you mentioned. How you do this will depend on your app server and will affect performance, but shouldn't be a problem.
I think you should definately decide up front what's going in different app servers, I dunno if 3 would work in the same app server.
Why do you would want to use multiple app servers?
Why not have everything in the same app?
Is is just the 1 database?
You can use clustering for scalability.

CMP Entity Bean with database specific features

Hi there,
I�m studying Entity Beans and I'm doing some experiences with SQL Server.
At first, I built a CMP Bean and marked in deploytool to create the tables. Ok, it worked.
Now, I'm trying to interact to an existent database. But, I got a problem: the primary key is defined by the Server. I can read it and I can remove entries. But, when I try to insert some entry, I can't pass the key in SQL statement. I edited the generated statement to do it, but it doesn't work. I get a RollbackException.
My question is: is it possible to do what I'm intending to do with CMP? What am I doing wrong?
Do you think that, to do this, I should use BMP Entity beans?
Thanks in advance,
Anicio

"CMP provides you with database independence and less coding efforts."
BMP is not database dependent, unless you invoke database specific things in your SQL (something I do not do). CMP on the otherhand is inherently appserver specific (which was it's goal when BEA, IBM, et al. came up with it), and still limits your design possibilities. See this thread for an example:
http://forum.java.sun.com/thread.jsp?forum=13&thread=318785
As for less coding effort, that is a relative statment. Yes a simple CMP bean requires less coding to develop the first time. I personally view a few lines of SQL to load and store the data as being fairly trivial. But that needs to be offset with the problems inherent in using appserver specific CMP implementations.
As an example, try mapping WebSphere CMP to a pre-existing database without using IBM's IDE. It's an incredible pain in the ass since WebSphere does not come with a "meet-in-the-middle" solution. Any J2EE developer that has had the experience of working with different appservers (especially if they have had to port an app, as I have) can attest to the complications that arise with each implementation.
A BMP bean, written with non-DB-specific SQL, is the most portable, most flexible approach to EntityBeans. Yes, it requires the developer to be able to write some SQL, which should not take a significant amout of time. WRT queries, you have to write them, either SQL, EQL, or some appserver specific format.
As an aside, the use of code generators to simplify the creation of EJBs lends itself well to BMP. By using a (or writing your own) code generator, you can mitigate the annoying SQL bugs that creep up early in development.

Re: junit test for entity beans ... ejb 3.0

I'm confused. I'm trying to test my entity bean.
I have:
- an entity bean
- a stateless session bean for accessing the entity bean (facade)
- an interface for accessing the the stateless bean
And I'm trying to write a JUnit test class to test this bean. However, I am uncertain as to how to test this (I'm new to EJB 3.0, JBoss and Eclipse).
What would the JUnit test look like? I'm confused as to whether or not I should be injecting the interface/bean/what???
I've tried several variations. I either get "NameNotFound" - not bound exceptions or Null pointer exceptions.
What would the @EJB syntax look like or how would I do it through the context?
For Example:
@EJB private TestFacade myTest; //interface to stateless bean ?
OR
InitialContext ctx = new InitialContext();
TestResultFacadeBean myTest = (TestResultFacadeBean) ctx.lookup("localTest");
I'm confused at to which method I should be using and what object I should be accessing. If I could get either one to work, I'd be happy. :)
How do I ensure my bean is deployed to the container? What do I need to do?
If anyone has a simple example or explanation as to which method I should use and how to use it, I'd be very grateful.
Thanks very much,
LisaD

OK, you need to have several layers of testing.
Layer 0. Test the entity beans are deployable (more on this later). Basically, you need to know that all your annotations work. Things to watch out for are multiple @Id fields in one class or @EmbeddedID or @IdClass in conjuction with @ManyToOne, @ManyToMany, @OneToMany, @OneToOne and fun with @JoinTable, @JoinColumn and @JoinColumns. Once you know how these are supposed to work with the spec, it's not too bad to write it correctly each time. But there are some gotchas that will break things later on.
Layer 1. Do the functions in the classes that don't depend on annotations work as expected. Typically, this is just going to be the getters and setters in your entity classes. Of course JUnit best practice says we don't bother testing functions that look like:
public T getX() {
return this.x;
or
public void setX(T x) {
this.x = x;
as there is nothing that can go wrong with them. So in that case, your level 1 tests will just be initial values specified from constructors and verifying that the non-get/set pairs work, and that the getters you have tagged @Transient work (because you've likely put some logic in them)
Layer 2. Test the session bean methods that don't require injection to work.
Layer 3. Test the session bean methods that require injection (Mock Objects). Simulate the injection for yourself, injecting Mock Objects for the entity manager. Then you can confirm that the correct methods are being called in the correct sequences, etc.
[Note this may require some skill in designing the mock. I'm working on developing my own entitymanager mock, and if it looks usefull I'll release it to the world.
Layer 4. Test the session bean methods that require injection (Real entity manager) (See Layer 0)
For this you will need an out of container persistence implementation. Currently Hibernate and Glassfish provide beta versions. You will need a different persistence.xml file that lists all the entities. You will have to use reflection to inject the entity manager(s) that you create from an entity manager factory unless you provide a constructor that takes an EntityManager as a parameter. You may need to use reflection to call any @PostConstruct method if you made it private.
Layer 5. Navigate the relationships in the objects returned from Layer 4 using a database that has been loaded with test data.
I am currently using Layers 0, 1, 2 & 4 to test my session beans and entity beans.

Regarding ENTITY bean local interfaces

Hi all,
I have a component session bean - containing a number of service methods for creating, retrieving, updating & deleting instances of a related entity bean. This session bean is used by another session facade bean, which invokes the various service methods in some sequence to complete a major task.
In the component session bean, the retireve methods return the local interface of the entity bean - on which it operates. The update methods accespt local interfaces of entity bean which can be directly updated.
My question is : Is it a right approach to pass the entity bean instances between method calls.
Thanks in advance,
Baskar

Your pointers regarding pt 2 was nice. Thanks.
This being my first J2ee design, I'am just collecting as much information as possible to stay confident.
Later, I started thinking a bit more regarding pt 1.
Where, I decided using individual session beans for different components(representing unique functionalities).
i.e,, I'am just thinking, should I use individual session beans for each of these different components.
What if I use standard java classes - implementing pre-defined interfaces for each of these components & use the components through these interfaces in session facade.
Now, I'll be using entity bean creates/retrieves/updates/deletes from inside normal java classes.
I thought, this would obviate the need for JNDI lookups - each time I want to use the components in my session facade.
But, I'am not sure of where this will impact..As far as I can visualize, this seems to be normal. Please share ...your thoughts regarding this. (something regarding transactions ??)

NON-transactional session bean access entity bean

We are currently profiling our product using Borland OptmizeIt tool, and we
found some interesting issues. Due to our design, we have many session beans which
are non transactional, and these session beans will access entity beans to do
the reading operations, such as getWeight, getRate, since it's read only, there
is no need to do transaction commit stuff which really takes time, this could
be seen through the profile. I know weblogic support readonly entity bean, but
it seems that it only has benefit on ejbLoad call, my test program shows that
weblogic still creates local transaction even I specified it as transaction not
supported, and Transaction.commit() will always be called in postInvoke(), from
the profile, we got that for a single method call, such as getRate(), 80% time
spent on postInvoke(), any suggestion on this? BTW, most of our entity beans are
using Exclusive lock, that's the reason that we use non-transactional session
bean to avoid dead lock problem.
Thanks

Slava,
Thanks for the link, actually I read it before, and following is what I extracted
it from the doc:
<weblogic-doc>
Do not set db-is-shared to "false" if you set the entity bean's concurrency
strategy to the "Database" option. If you do, WebLogic Server will ignore the
db-is-shared setting.
</weblogic-doc>
Thanks
"Slava Imeshev" <[email protected]> wrote:
Hi Jinsong,
You may want to read this to get more detailed explanation
on db-is-shared (cache-between-transactions for 7.0):
http://e-docs.bea.com/wls/docs61/ejb/EJB_environment.html#1127563
Let me know if you have any questions.
Regards,
Slava Imeshev
"Jinsong HU" <[email protected]> wrote in message
news:[email protected]...
Thanks.
But it's still not clear to me in db-is-shared setting, if I specifiedentity
lock as database lock, I assumed db-is-shared is useless, because foreach
new
transaction, entity bean will reload data anyway. Correct me if I amwrong.
Jinsong
"Slava Imeshev" <[email protected]> wrote:
Jinsong,
See my answers inline.
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
Hi Slava,
Thanks for your reply, actually, I agree with you, we need to
review
our db
schema and seperate business logic to avoid db lock. I can not say,guys,
we need
to change this and that, since it's a big application and developedsince
EJB1.0
spec, I think they are afraid to do such a big change.Total rewrite is the worst thing that can happen to an app. The
better aproach would be identifying the most critical piece and
make a surgery on it.
Following are questions in my mind:
(1) I think there should be many companies using weblogic serverto
develop
large enterprise applications, I am just wondering what's the maintransaction/lock
mechanism that is used? Transional session / database lock,
db-is-shared
entity
I can't say for the whole community, as for my experience the standard
usage patthern is session fasades calling Entity EJBs while having
Required TX attribute plus plain transacted JDBC calls for bulk
reads or inserts.
is the dominant one? It seems that if you speficy database lock,
the
db-is-shared
should be true, right?Basically it's not true. One will need db-is-shared only if thereare
changes
to the database done from outside of the app server.
(2) For RO bean, if I specify read-idle-timeout to 0, it shouldonly
load
once at the first use time, right?I assume read-timeout-seconds was meant. That's right, but if
an application constantly reads new RO data, RO beans will be
constantly dropped from cache and new ones will be loaded.
You may want to looks at server console to see if there's a lot
of passivation for RO beans.
(3) For clustering part, have anyone use it in real enterpriseapplication?
My concern, since database lock is the only way to choose, how aboutthe
affect
of ejbLoad to performance, since most transactions are short live,if high
volume
transactions are in processing, I am just scared to death about
the
ejbLoad overhead.
ejbLoad is a part of bean's lifecycle, how would you be scared ofit?
If ejbLoads take too much time, it could be a good idea to profile
used SQLs. Right index optimization can make huge difference.
Also you may want cosider using CMP beans to let weblogic
take care about load optimization.
(4) If using Optimization lock, all the ejbStore need to do
version
check
or timestamp check, right? How about this overhead?As for optimistic concurrency, it performs quite well as you can
use lighter isolation levels.
HTH,
Slava Imeshev
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
We are using Exclusive Lock for entity bean, because of we do
not
want
to
load
data in each new transaction. If we use Database lock, that means
we
dedicate
data access calls to database, if database deadlock happens,
it's
hard
to
detect,
while using Exclusive lock, we could detect this dead lock in
container
level.
The problem is, using Exclusive concurrency mode you serialize
access to data represented by the bean. This aproach has negative
effect on ablity of application to process concurrent requests.As
a
result the app may have performance problems under load.
Actually, at the beginnning, we did use database lock and usingtransactional
The fact that you had database deadlocking issues tells that
application logic / database schema may need some review.
Normally to avoid deadlocking it's good to group database
operations mixing in updattes and inserts into one place so
that db locking sequence is not spreaded in time. Moving to
forced serialized data access just hides design/implementation
problems.
session bean, but the database dead lock and frequent ejbLoad
really
kill
us,
so we decided to move to use Exclusive lock and to avoid dead
lock,
we
change
some session bean to non-transactional.Making session beans non-transactions makes container
creating short-living transactions for each call to entity bean
methods. It's a costly process and it puts additional load to
both container and database.
We could use ReadOnly lock for some entity beans, but since weblogicserver will
always create local transaction for entity bean, and we found
transaction
commit
is expensive, I am arguing why do we need create container leveltransaction for
read only bean.First, read-only beans still need to load data. Also, you may seeRO
beans
contanly loading data if db-is-shared set to true. Other reason
can
be
that
RO semantics is not applicable the data presented by RO bean (forinstance,
you have a reporting engine that constantly produces "RO" data,
while
application-consumer of that data retrieves only new data and neverasks
for "old" data). RO beans are good when there is a relatively stable
data
accessed repeatedly for read only access.
You may want to tell us more about your app, we may be of help.
Regards,
Slava Imeshev
I will post the performance data, let's see how costful
transaction.commit
is.
"Cameron Purdy" <[email protected]> wrote:
We are currently profiling our product using Borland
OptmizeIt
tool,
and we
found some interesting issues. Due to our design, we have
many
session
beans which
are non transactional, and these session beans will access
entity
beans
to
do
the reading operations, such as getWeight, getRate, since
it's
read
only,
there
is no need to do transaction commit stuff which really takes
time,
this
could
be seen through the profile. I know weblogic support readonly
entity
bean,
but
it seems that it only has benefit on ejbLoad call, my test
program
shows
that
weblogic still creates local transaction even I specified
it
as
transaction not
supported, and Transaction.commit() will always be called
in
postInvoke(),
from
the profile, we got that for a single method call, such as
getRate(),
80%
time
spent on postInvoke(), any suggestion on this? BTW, most of
our
entity
beans are
using Exclusive lock, that's the reason that we use
non-transactional
session
bean to avoid dead lock problem.I am worried that you have made some decisions based on an improper
understand of what WebLogic is doing.
First, you say "non transactional", but from your description
you
should
have those marked as tx REQUIRED to avoid multiple transactions
(since
non-transactional just means that the database operation becomesits
own
little transaction).
Second, you say you are using exclusive lock, which you shouldonly
use
if
you are absolutely sure that you need it, (and note that it
does
not
work in
a cluster).
Peace,
Cameron Purdy
Tangosol, Inc.
http://www.tangosol.com/coherence.jsp
Tangosol Coherence: Clustered Replicated Cache for Weblogic
"Jinsong Hu" <[email protected]> wrote in message
news:[email protected]...
>

Entity Bean can only use container-managed transaction demarcation?

In <<Designing Enterprise Application with J2EE 2nd>>
Section 2.3.3.3 Enterprise Bean Transactions,it says:Entity beans can only use container-managed transaction demarcation.
That means,i can not get UserTransaction from EJBContext.
Is that true?

Yes this is the requirement of the specs. Your ejb code generator should give you the error if you use usertransaction.
--Ashwani

CMP Entity Bean from dataBase views

Hi forum,
I Have to migrate an existing application to JEE (with EJB3).
In this application there are a lot of dataBase views.
I'm new in EJB3 and I don't know how to structure cleanly entity beans (Specially when it are created from dataBase views).
My problem is that for each query made from the same dataBase view I almost have to create a new entity bean with a different @Id.
What can I do to to avoid it?
I had thought to genrate a new @Id (attribute not persistent) but I think is not possible. It's right ?
Someone can help me ?
Thanks

"CMP provides you with database independence and less coding efforts."
BMP is not database dependent, unless you invoke database specific things in your SQL (something I do not do). CMP on the otherhand is inherently appserver specific (which was it's goal when BEA, IBM, et al. came up with it), and still limits your design possibilities. See this thread for an example:
http://forum.java.sun.com/thread.jsp?forum=13&thread=318785
As for less coding effort, that is a relative statment. Yes a simple CMP bean requires less coding to develop the first time. I personally view a few lines of SQL to load and store the data as being fairly trivial. But that needs to be offset with the problems inherent in using appserver specific CMP implementations.
As an example, try mapping WebSphere CMP to a pre-existing database without using IBM's IDE. It's an incredible pain in the ass since WebSphere does not come with a "meet-in-the-middle" solution. Any J2EE developer that has had the experience of working with different appservers (especially if they have had to port an app, as I have) can attest to the complications that arise with each implementation.
A BMP bean, written with non-DB-specific SQL, is the most portable, most flexible approach to EntityBeans. Yes, it requires the developer to be able to write some SQL, which should not take a significant amout of time. WRT queries, you have to write them, either SQL, EQL, or some appserver specific format.
As an aside, the use of code generators to simplify the creation of EJBs lends itself well to BMP. By using a (or writing your own) code generator, you can mitigate the annoying SQL bugs that creep up early in development.

Lookup Data ( Readonly Entity Bean)

My application has a requirement for multiple lookup data ( asset types ,
broker types ) with code and description. The lookup data is fairly static
and only updated through an external source.Can I use a read only BMP Entity
EJB. The primary key will be the lookup type.
Is this a good pattern or are any other efficient ways to achieve the same
thing.
John.

That fits quite well into what ReadOnly entity beans are designed for.
Charles
"John" <[email protected]> wrote:
My application has a requirement for multiple lookup data ( asset types
broker types ) with code and description. The lookup data is fairly static
and only updated through an external source.Can I use a read only BMP
Entity
EJB. The primary key will be the lookup type.
Is this a good pattern or are any other efficient ways to achieve the
same
thing.
John.

Entity bean mapping to multiple tables.

Hello,
Is it possible to map several tables with only one BMP?
if so please send me an example (class bean)
Thanks in advance

hi,
yes, entity bean can be mapped to multiple tables provided it is bean managed entity bean.
since, container cannot prepare complex quries so that we need to rely on bean managed persistance.
Ex : Assume you have two table like X, Y
where X table having fields (int x primarykey, varchar str) and Y table having fields (varchar name primarykey, int y).
Now you should design a primary key class of your own as shown below:
public class BeanPriamkey implements java.io.Serializable
protected int x;
protected String name;
public BeanPramkey()
//initialzation part
public BeanPramkey(int x,String str)
//initialzation part
public String toString()
//return object value as string
public int hashCode()
//return an int value
public boolean equals(BeanPramkey)
public int getX()
return x;
public String getStr()
return str;
now your entity bean would be like this
public class Mybean implements EntityBean
int x,y;
String str,name;
BeanPriamkey primekey;
public BeanPrrmkey ejbCreate(int x,String name)
//fetch the rows from the tables X and Y ;
//if the rows exists int the tables create beanprimkey object with x and name and return refernce of the Beanprimkey class object
public BeanPrimkey findByPrimarykey(BeanPrimkey )
//first extract values of x and str from BeanPrimkey
and chek X and Y table for corresponding rows if exists return the reference of BeanPrimkey else return null
public void ejbStore()
BeanPrimkey prikey = (BeanPrimkey) entityContext.getPrimarykey();
int x = prikey.getX();
String st = prikey.getStr();
update X and Y tables using x and str;
public void ejbLoad()
BeanPrimkey prikey = (BeanPrimkey) entityContext.getPrimarykey();
int x = prikey.getX();
String st = prikey.getStr();
fetch the rows from X and Y tables using x and str;
and assing the row values to bean instance variables.
public void ejbPassivate()
//code for release the resources
public void ejbActivate()
//code for aquiring the resource
public void setEntityContext(EntityContext ec)
this.ec = ec;
protected EntityContext ec;

Can't deploy Simple 2.0 CMP Entity Bean into Sun One Server 7

Dear all:
I use JBuilder9 + SunOne Plug-in to
build a Simple Entity Bean, but I can't
deploy it into SunOne 7 Server that return
error message:
Deployment Error -- Error while running ejbc -- Fatal Error from EJB Compiler -- -- Error while processing CMP beans.
But I use JBuilder9 + JBoss 3.x Plug-in
that corrent run on JBoss 3.2 RC
All code are generated by JBuilder9 EJB Designer
and only have PK finder.
Our deploy description flile are:
ejb-jar.xml=============================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
<ejb-jar>
<enterprise-beans>
<entity>
<display-name>Enterprise1</display-name>
<ejb-name>Enterprise1</ejb-name>
<home>untitled1.Enterprise1RemoteHome</home>
<remote>untitled1.Enterprise1Remote</remote>
<local-home>untitled1.Enterprise1Home</local-home>
<local>untitled1.Enterprise1</local>
<ejb-class>untitled1.Enterprise1Bean</ejb-class>
<persistence-type>Container</persistence-type>
<prim-key-class>untitled1.Enterprise1PK</prim-key-class>
<reentrant>False</reentrant>
<cmp-version>2.x</cmp-version>
<abstract-schema-name>Enterprise1</abstract-schema-name>
<cmp-field>
<field-name>inDate</field-name>
</cmp-field>
<cmp-field>
<field-name>sndSeq</field-name>
</cmp-field>
<cmp-field>
<field-name>msgSnd</field-name>
</cmp-field>
<cmp-field>
<field-name>msgRcv</field-name>
</cmp-field>
<cmp-field>
<field-name>brkId</field-name>
</cmp-field>
</entity>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>Enterprise1</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
=================================
sun-ejb-jar.xml=====================
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.0 EJB 2.0//EN' 'http://www.sun.com/software/sunone/appserver/dtds/sun-ejb-jar_2_0-0.dtd'>
<sun-ejb-jar>
<enterprise-beans>
<ejb>
<ejb-name>Enterprise1</ejb-name>
<jndi-name>Enterprise1Remote</jndi-name>
</ejb>
<pm-descriptors>
<pm-descriptor>
<pm-identifier>IPLANET</pm-identifier>
<pm-version>1.0</pm-version>
<pm-class-generator>com.iplanet.ias.persistence.internal.ejb.ejbc.JDOCodeGenerator</pm-class-generator>
<pm-mapping-factory>com.iplanet.ias.cmp.NullFactory</pm-mapping-factory>
</pm-descriptor>
<pm-inuse>
<pm-identifier>IPLANET</pm-identifier>
<pm-version>1.0</pm-version>
</pm-inuse>
</pm-descriptors>
<cmp-resource>
<jndi-name>jdo/sample-cmp</jndi-name>
<default-resource-principal>
<name>mv01</name>
<password>mv01</password>
</default-resource-principal>
</cmp-resource>
</enterprise-beans>
</sun-ejb-jar>
===========================
sun-cmp-mappings.xml===============
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-cmp-mappings PUBLIC '-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.0 OR Mapping //EN' 'http://www.sun.com/software/sunone/appserver/dtds/sun-cmp-mapping_1_0.dtd'>
<sun-cmp-mappings>
<sun-cmp-mapping>
<schema>META-INF/mySchema</schema>
<entity-mapping>
<ejb-name>Enterprise1</ejb-name>
<table-name>TSE_MSG_T</table-name>
<cmp-field-mapping>
<field-name>inDate</field-name>
<column-name>INDATE</column-name>
</cmp-field-mapping>
<cmp-field-mapping>
<field-name>sndSeq</field-name>
<column-name>SNDSEQ</column-name>
</cmp-field-mapping>
<cmp-field-mapping>
<field-name>msgSnd</field-name>
<column-name>MSGSND</column-name>
</cmp-field-mapping>
<cmp-field-mapping>
<field-name>msgRcv</field-name>
<column-name>MSGRCV</column-name>
</cmp-field-mapping>
<cmp-field-mapping>
<field-name>brkId</field-name>
<column-name>BRKID</column-name>
</cmp-field-mapping>
</entity-mapping>
</sun-cmp-mapping>
</sun-cmp-mappings>
=========================

I remember getting errors like that. The only thing I see is in the map file. When I
did mine I used TABLENAME.CMPFIELD to map columns to CMP attributes.
TSE_MSG_T.INDATE
TSE_MSG_T.SNDSEQ
for column names in the sun-cmp-mappings.xml file.
For any other errors set the logging for server1 or which one you are using to "finest".
Try the deploy, shut down the server, and when you view the log, start at the bottom
and keep scrolling up to the top of each stack trace and you should get a more
specific error explanation at about the 3rd or 4th stack trace.

Choosing session vs. entity bean

I am working on a web application that (among other things) needs to occasionally persist data in a database. I am using a DBUtil class that actually gets the DB connection and makes the update - all i do is pass it a string that represents the SQL statement. I want to create an EJB that can store a queue of statements (passed from the web classes) and periodically send them off to another EJB that will use the DBUtil class to do batch updates on the database.
I need to determine which types of EJBs to use for the 2 beans. If the first bean (the one that queues up the SQL statements and periodically sends them along) is only going to be accessed by one client, should I just use a session bean? Or do I need to use an entity bean because the bean needs to 'sleep' between its periodic call to the other bean?
The second bean simply waits to receive the set of SQL statements from the first bean and then passed them along to the DBUtil class for insertion into the DB. I was going to make this a session bean, but it seemed odd to have an entity bean calling a session bean (if the first bean should indeed be a entity bean). Are there any reasons why the second bean should be an entity bean instead of a session bean.
Thanks.

Hi,
I think the design to use EJBs for implementing a kind of service which accumulates a set of db statements and then update the db does not call for the use of EJBs. This service could be implemented using simple java classes easily and then when a predefined threshold is reached, you can call the DBUtil class to update the db. In case you want to de-couple the task of updating the db then, on reaching the threshold post a message to a queue and then write a MDB which listens for this and it calls the DBUtil to do the update.
If you want to run all your db statements in a context of a transaction, you can use a stateless session bean to call the DBUtil, but again the service has to be in a java class.
Otherwise I dont see the use of EJBs, especially two beans one calling the other as stated by you as a good design.
Regards,
Naveen

Entity bean design

Similar Messages

Maybe you are looking for