Brian,
Surely the problem has very little to do with JBoss or EJB's.
Both Entity Beans and Message Driven Beans operate in a transaction context set
by the EJB server.
So, when your entity bean reads row #0 (or whichever), it takes a database lock
on this row in case the entity bean intends to
Andy,
This sort of problem is always a real hassle.
I don't know the Tomcat internals at all. You may be able to switch on Log4J
logging for some of the Tomcat internal classes to get a clue.
The timing of the problem - after days of application usage - strongly suggests
a problem somewhere w
Andy,
This feels like (but may not be) the problem of not properly releasing a
connection after use. I assume that you are using BMP.
Your code should look like :-
| public void ejbLoad() {
|
| Connection conn = null;
| PreparedStatement statement = null;
| InitialCon
I don't know why you need two stateful session beans.
Most design problems resolve themselves to stateless session beans that invoke
operations on (or send messages to) entity beans that represent the business
data.
You should be able to send messages to the consumer session bean B by producer
Also see this discussion on February 14th. in the design patterns area :-
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=60216
James
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3872044#3872044
Reply to the post :
http://www.jboss.org/index.html?
I would suggest Eclipse (free) with the JBoss plugin.
See the separate forum on Eclipse.
If you adopt Eclipse, make sure that you install a stable, tested version.
Don't use alpha or beta releases.
James
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=38708
Static method calls are a very useful tool but have limitations.
You cannot access a static method from outside the JVM in which the class
resides.
And there are potential concurrency issues if your static methods access shared
data. One thread may change data on which another thread relies.
There isn't a good way to reload stateless Session Beans, and there isn't meant
to be.
Suggestions :-
a)Move the read only data from the Session Beans to a singleton Java class
within the application Server. Reload data in the Singleton either when a
timestamp expires or by touching the s
Hi,
See also my response to your other query.
Direct access from the web tier is probably undesirable because it breaks the
model and will probably make it difficult to generate ther correct HTML within
Struts.
A better solution is to introduce an application server tier and to store the
vari
Hi.
If anybody has firm metrics on this, they are keeping them to themselves.
There are definite advantages in introducing an application tier. It allows
you to set up entity beans representing validation data (see your other query)
which greatly reduces the load on the database and thus respo
Kalyan,
I'm not quite sure where you are coming from.
The code sample that you include won't compile (attribute home is not defined).
The class is not a session bean (doesn't implement the SessionBean interface).
The class is not a singleton (doesn't have a private constructor and a
getInstanc
kevliang,
I think that everything you suggest will work, except that I don't know whether
you can register an mbean with JNDI.
I have found it possible to use an entity bean as a singleton by defining a
single constant value as the primary key. The constant value is defined
somewhere in the p
An alternative approach is to strip all the time information from the date
before storing the date in the database.
This works well in commercial applications but may not suit your application.
James
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3866049#386
James,
This problem comes up quite frequently.
Java requires the serialVersionUID of the class to be identical on the object
sent across the network by RMI and the locally loaded class that is meant to
rebuild the object.
As you are using two different versions of JBoss, you are getting difere
Hi,
Don't worry too much.
Apache Derby is IBM (ex Sybase) Cloudscape donated to the open source community
and rebadged.
If you use stand alone processes, only one process can access Cloudscape/Derby
databases - as you know.
But IBM also provided a server that would allow multiple connections,
Well Nicolas,
BMP won't go back to reload from the database because it sees a primary key "2"
that it believes that it has already loaded.
I suggest that you prefix each ID field in the BMP entity bean with the name of
the table as below :-
table1/2
| table2/2
|
This gives each combinati
Brian,
It doesn't quite work like that !
With Stateless Session Beans, the container maintains a pool of Stateless Session
Beans in the container.
Each client instance that calls a method on the SSB is handed a reference to one of
the idle SSB's in the pool. So there should never be two clien
Presumably you are using CMP.
My guess is that the client.getOrders().iterator() statement is getting a set of
Primary Keys for the order.
As you progress through the iterator, each order in turn is loaded in a separate SQL
statement.
So, for n orders, the application is making n+1 SQL operati
This is one that comes up regularly, and there are several areas that you need to
check.
The fact that you are getting two ejbLoad() calls and one ejbStore() call suggests
that the entity bean may not be taking part in the transaction that you have declared.
Check in the deployment descriptor
Villo,
A cursory look at OJB suggests that it should successfully load and store objects of
the different classes.
My approach to this problem would be to create an abstract super class above all the
actual user classes.
so you have a hierarchy :-
| public abstract class AbstractUser {
So we are envisaging a posdition where SLSB C1 calls in turn A, B, C, D and then calls
B again.
Meanwhile SLSB C2 has deleted B.
You can do one of several things :-
| 1. By locking A,B,C and D in a transaction you can prevent C2 deleting B.
| 2. Your code can anticipate and recover fro
But it is usually a bad idea to make the
solution more complex than the problem.
I normally stamp an object with the username of the interested user. This allows me
to produce error messages such as :-
| Order H0013 is locked by user jamesstrachan
|
The users involved can then sort it
Iain,
Pleased to help.
The commit-option of A, B or C controls reading from the database (not writing).
If you go the Wiki page and searcvh for "commit option", you will find a page that
explains this.
James
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3
Iain,
Going through your topics in order :-
Method names create, load, store, findByPrimaryKey and remove in the remote interface
are remapped by the container to ejbCreate() etc. Presumably this is to make sure
that the container can perform operations such as storing an in-memory copy, looki
Sanju,
I think that I see where you are having a problem.
The create() method on an entity bean does real work - it creates an object and
persists it.
The create() method on a session bean creates the session bean (which may initialse
variables etc.) but doesn't create the underlying object.
James,
I'll dig siomething out and post - but not till I get back home at the weekend !
James
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3848452#3848452
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3848452
-
Sanju,
If the deployment script is for a Session Bean, then it will prevent anybody who does
not have a role of "system" from accessing the bean.
If "HelloAssyt" was an entity bean representing persistent data (which seems unlikely
from the name of the EJB and the method name), it would allow a
Sanju,
You need to get the remote interface to execute any business methods.
So, if you don't have permission to execute the ejbCreate() method, you can't get the
remote interface and you can't execute a business method.
Don't forget that stateless and stateful session beans behave in a differe
Dave,
The trouble is that the answer is "it depends", not least because it depends on what
you are doing with the EJB's.
At one extreme, you may be using a set of session beans that have a little business
logic and JDBC statements to interact with the database. In that environment, it
probabl
I guess that you could get a race between MDB2 starting and MDB1 committing if (a) you
use a file based JMS persistence manager and (b) you are not including the JMS
messages in the transaction. Then it is possible for the thread running MDB2 to start
before the thread in MDB1 has finished.
Th
It's very difficult to tell what is happening here.
It could be a database locking problem. You can test this using SQL commands outside
the application server.
Or it could be a JBoss locking problem, as JBoss also operates a locking strategy on
entity beans.
Or it could be a locking problem
You found the bug, not me.
I missed that one.
James
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845777#3845777
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3845777
--
Are you getting any errors when you deploy the jar file ?
If you get any messages similar to :-
Instance of primary key not located
that would indicate a problem.
And are you getting any error messages or stack traces when you call the ejbCreate()
method ?
James
View the original post :
ht
Although you are returning an AccountPK object from your ejbCreate() method, you are
not storing an AccountPK object inside the Entity Bean itself.
So JBoss cannot locate or handle the Entity Bean.
You need to add as shown below :-
| System.out.println("ejbCreate() Called.");
|
If we take out the timing code, what you are doing is :-
| For each entry in index {
| Get entity bean for index
| Get ID
| Get value
| }
|
Getting the entity bean involves network I/O, and also requires that the server works
to create the Entity Bean and to load its dat
You are suggesting three alternatives :-
1. Restart from 1 after each purge;
2. Use a unique generated number - a GUID (Global Unique ID);
3. Use a two part number.
All three are workable, although (2) would probably meet serious resistance from
users. They like to see understandable, sequen
Therion,
You need to use a different EJB name as well as a different JNDI name.
The partial deploymeent descriptor below is an example :-
|
| Audit Logging SSB
| AuditLoggingReceiver
| com.syntegra.nhs.nasp.tms.logging.LoggingReceiverHome
| com.syntegra.nh
Adrian,
I suspect that you will need to code and deploy your socket link to COM as a JMX MBean
- rather like a database source.
But I've never tried this. Anyone from JBoss who can contribute ?
James
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3843204#3
Try something like this, which uses package names to separate the streams :-
|
|etc.
|
|
|
|etc.
|
|
|
|
|
|
|
|
|
|
|
|
|
The example is incomplete but shows the principle.
All events fron classes in packages commencing "co
Phil,
What I think is happening is this :-
Your reference in the ejb link shows that you are expecting to look up an EJB with a
JNDI name of Customer.
You can confirm in the JNDI view, or in the MBean view, that you are actually
deploying one entity bean with the JNDI name Customer.
Assuming
Phil,
It would seem that both EJB's have the same JNDI name. Deployment of the second EJB
overwrites the first JNDI name so that only the second is referenced.
Presumably, as the deployer, you haver control of the Deployment Descriptors.
You can do one of two things. Either change the ejb-ref
This requires a longer explanation.
For stateless session beans, JBoss uses a pool of beans and supplies the client with
any instance. In a idle system (normal developer mode), JBoss will create a pool with
one instance and give you that instance on each call.
Your client does a create() and t
The timer code is, as you have guessed, in the onMessage() method. The timeout is
checked before doing work so that anything out of date can be refreshed.
You can then read directly from Preferences, a Properties file, or an Entity bean as I
suggested. You may have problems reading a file as t
Let's start with the timer, as that's simple.
You use an environment variable in the deployment descriptor to set a reload interval
in seconds.
You then read that and covert it to milliseconds
|
| Integer temp = context.lookup( "java:comp/env/ReloadInterval");
| reloadInterval = temp.get
I would suggest :-
Use an Entity Bean to hold the configuration data. This will give you persistence.
The Entity Bean can be either a singleton (see earlier discussion) or a set of Entity
Beans with a key for each parameter.
The Entity Bean can then be updated from a web client or Java clien
Roll,
The first thing to release is that, once you apply security, ALL EJB method calls must
be accompanied by principal and credentials. Your client (assuming that it is a heavy
client) has to store principal and credentials in the client context and supply these
with every call.
You could w
Vishal,
Have a look at the discussion chain on topic :-
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=50863
That provides a complete solution to a similar problem with two differences.
Diff. 1
That problem was for a singleton solution, in which only one Entity Bean exists in the
Gareth,
The EJB Specification mandates that (a) ejbLoad() must be called before a business
method in a transaction is executed, and that (b) ejbStore() must be called after a
business method is executed.
a) is designed to prevent a business method in a transaction being executed on data
that
I forgot to mention that the next ticket number bean should also implement the
"Singleton EJB" pattern as you should enforce a rule that only one component issues
next numbers.
I suggest that you persist the last number used. You should then get a uniformly fast
response to each query, at the
Elementaries
1. Check that there is no transient modifier on variables in the Javabean.
2. Check that the Javabean class, and any classes that it references, are on the
classpath in the remote JVM.
3. Supply sample code for servlet, Javabean and session bean to see if anybody can
spot a
John,
If I had known you were going to do this, I would have given you different advice !
You are obviously running out of memory in the heap because of the number of integer
ticket numbers stored and the overheads (hidden to you) of the objects in the tree set.
You can increase the size of the
I don't know whether you are trying to deploy a session bean or entitry bean, but here
is an example of both xml descriptors that works.
|
| Fragment from ejb-jar.xml
|
|
| Menu Option Use Case Session Bean
| milton/appmenu/optionmaint
| org.mil
I have tested this on another J2EE server (no names, no pack drill) and found that the
home interface appears to contain data specific to the server instance - perhaps a
memory address or object within the server.
Stopping and restarting the server makes this reference invalid, leading to the er
John,
>From your description, what you need is an entity bean that contains the entire list
>of numbers.
The bean acts as a singleton (if you know the Gang of Four book) with only one bean
ever present in the server. You enforce the singleton rule by using a published
primary key with a const
Brace yourselves, here is the complete code :-
| //Package: Security Objects
| //Class:SecurityRoleSetBean
| //Version: 1.0
| //Copyright:Copyright (c) 2002
| //Author: James Strachan
| //Company: Milton Software Components
| //Description: Entity B
Nano,
I have just had to deal with a very similar problem in another application server.
I would suspect that your home reference, which you get as you initialise the servlet,
contains internal information which becomes out of date when your colleague does a hot
deploy.
This will then lead to
David,
I would suggest that you use an Entity Bean that contains the contents of the view.
The Entity Bean should have an artificial key, as shown below, so that one and only
one instance ever exists.
/**
* This static string will be used to define the key for the Singleton Role Set.
*/
57 matches
Mail list logo
