This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes EJB and other Java EE Technologies and the fly likes Architectural question about EJBs Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Architectural question about EJBs" Watch "Architectural question about EJBs" New topic
Author

Architectural question about EJBs

Julien Martin
Ranch Hand

Joined: Apr 24, 2004
Posts: 384
Hello,
I have a complex object that cannot be represented in a database and which has lots of business methods. I would like for this object to be available to the whole of the application e.g. a client (a servlet) calls a getter on a property of that object and the same value is returned that would be for another client (for instance a swing client). I would like for this object to be transactionally safe and ideally for this object to be an ejb. I am at a loss on how to implement this. I guess I need to use a singleton pattern somewhere.
Can anyone help?
Thanks in advance,
Julien Martin.
Ådne Brunborg
Ranch Hand

Joined: Aug 05, 2005
Posts: 208
Basically, what you want is to designe a SessionEJB, which, for all instances of that EJB, isIdentical() will always return true, right? Bad idea, 'cause that means there's only one instance of that EJB running, ever, which means that you are killing performance.

Another way is to design the EJB's to access a singleton. This is possible, however you can only gurantee that myobject1.equals(myobject2) within one JVM, and since EJBs are designed to be deployed across multiple JVMs, this is a bad idea.

You need to represent the object in a persistent store, somehow. If you create a database table, containing the key of MyObject. Then, you create an EntityEJB that maps to this key, and implement your business methods on this. This way, isIdentical() will return true for all instances of MyObjectEJB with identical keys. So all is well. Or is it?

No. 'Cause if you make getter methods on the EntityEJB, unless they are written to the database, they exist only in that instance of the object, and even though isIdentical() will return true, equals() is not guranteed to return true, which means the objects are different, which means you cannot gurantee the same getters returning the same.

I cannot see any way to gurantee getters returning the same, unless the properties returned by those getters are written to a persistent store. Which, judging from your statement "represented in a database" is not possible.

Or, do you mean "cannot be represented by a single table in the database"?

Don't know if this was any help. But sounds like you need to design a database...
[ October 16, 2006: Message edited by: �dne Brunborg ]

Entia non sunt multiplicanda praeter necessitatem
Jesus Angeles
Ranch Hand

Joined: Feb 26, 2005
Posts: 2049
Originally posted by Julien Martin:
Hello,
I have a complex object that cannot be represented in a database and which has lots of business methods. I would like for this object to be available to the whole of the application e.g. a client (a servlet) calls a getter on a property of that object and the same value is returned that would be for another client (for instance a swing client). I would like for this object to be transactionally safe and ideally for this object to be an ejb. I am at a loss on how to implement this. I guess I need to use a singleton pattern somewhere.
Can anyone help?
Thanks in advance,
Julien Martin.


It looks like you just described the reason why there is EJB. Your front may be a session bean. You may have mdb, entity bean, or other methodologies behind it.
Ådne Brunborg
Ranch Hand

Joined: Aug 05, 2005
Posts: 208
Originally posted by Jesus Angeles:


It looks like you just described the reason why there is EJB. Your front may be a session bean. You may have mdb, entity bean, or other methodologies behind it.


As I wrote above, you cannot gurantee the uniqueness of a singleton across multiple JVMs - if two client access two different JVMs, they will not access the same object. And accessing the same unique object from multiple clients is the major point here, as I understand it.

It is not a problem if you are only going to deploy it on a single JVM on a single machine, but that is making assumptions about something which might change in the future.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Architectural question about EJBs
 
Similar Threads
locking and the find method.
Stateful Bean as a data storege dump
Forwarding from an if statement
RMI: Remote and Movable Objects
Creating Objects using Factory Methods