Re: ReadOnly Entity Bean

Hi all,
I am trying to write a Read Only Entity bean which gets loaded once in the cache
and then the container refreshes it every x seconds.
Has anyone come across any example how to do this. That would really help.
Thanks...Kevin

RTFM http://e-docs.bea.com/wls/docs70/////ejb/reference.html#1139340 :
"ReadOnly used for read-only entity beans. Activates a new instance for each
transaction so that requests proceed in parallel. WebLogic Server calls
ejbLoad() for ReadOnly beans are based on the read-timeout-seconds
parameter."
In weblogic-ejb-jar.xml:
<concurrency-strategy>ReadOnly</concurrency-strategy>
<read-timeout-seconds>x</read-timeout-seconds>
Michael Jouravlev
"KW" <[email protected]> wrote in message
news:3cee3f67$[email protected]..
>
Hi all,
I am trying to write a Read Only Entity bean which gets loaded once in thecache
and then the container refreshes it every x seconds.
Has anyone come across any example how to do this. That would really help.
Thanks...Kevin

Similar Messages

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.

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]...
>

To use Entity Bean or Oracle stored Package?

Currently, in my project, Weblogic8.1 and Oracle is used, but lots of business logic is implemented using Oracle stored Packages, many of these packages have a package level readonly lookup table(like index-by table or nested table), which is populated with data from database, once the package is called, and is accessed very often in subsequent calls of stored procedures.
Since, in Weblogic server, a connection pool is maintained, and those package level lookup tables would be stored as session data in oracle PGA, I'm afraid this might cause oracle database server to be overloaded.
to fully take advantage of middleware cache service that weblogic provide, should I move those business logic out of oracle and implement them using like read only entity bean?
any help appreciated!

Its very hard to say without knowing the usage patterns of the data. It sounds like you have a lot of read-only entities. These could be spread around a WLS cluster, therefore there is more scalability and performance with this option. However, I would not neccessarily rewrite business logic from SP into EJB just for middle-tier caching.
If its a DB intensive app with lots of SQL, then if the calls are within SP's, there is only 1 call from WLS and the DBA ought o be able to tune the DB usin read-ahead and other DBA semantics. If there is locality of reference in the data, again, DB can use read-ahead better than WLS, although RO cache in middle is more scalable than DBMS.
I wouldnt rewrite business logic from SP to EJB/Entity beans to take advantage of cache, especially if there is no locality of read-only reference to data. Oracle could do this better in my opinion, especially if SP's already exist
Need for information on the usage patterns of the data - how is it CRUD'd.
I would use-case the steel threads and put them under test load to see if the SP's really are an issue, since this is an architecture decision. What state is the project at? Live/Dev? Inception?

Problem with Read-Only Entity Bean

Hi All,
I have an Read-Only BMP that just read data from 20 tables and stores them in a Collection. In a 'Read-Only' Entity bean, the ejbLoad() is supposed to called periodically as defined by 'read-timeout-seconds' parameter in 'weblogic-ejb-jar.xml'. But this doesn't happen. Every time I invoke the EJB, ejbCreate() and ejbLoad() get called. Any suggestions will be highly appreciated.
Here is the content of my 'weblogic-ejb-jar.xml' file.
<?xml version="1.0"?>
<!DOCTYPE weblogic-ejb-jar PUBLIC
'-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN'
'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>beanManaged</ejb-name>
     <entity-descriptor>
          <entity-cache>
               <max-beans-in-cache>1</max-beans-in-cache>
               <read-timeout-seconds>5</read-timeout-seconds>
               <concurrency-strategy>ReadOnly</concurrency-strategy>
          </entity-cache>
     </entity-descriptor>
<jndi-name>beanManaged</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
Thanks,
Prem

Yes, it calls ejbLoad() at intervals defined by read-timeout-seconds, but only when bean
is requested by the client, and the cached copy is old. If bean just sits in the cache
unused no ejbLoad()'s will be called.
Prem Raghupathy <[email protected]> wrote:
The weblogic document on 'Setting Entity EJBs to Read-Only' says "WebLogic Server
never calls ejbStore() for a read-only entity EJB. ejbLoad() is called initially
when the EJB is created; afterwards, WebLogic Server calls ejbLoad() only at intervals
defined by the read-timeout-seconds deployment parameter.". Here is the link to
the document
http://edocs.bea.com/wls/docs61/ejb/EJB_environment.html#1074846
Dimitri Rakitine <[email protected]> wrote:
WebLogic doesn't reload Read-Only entity beans periodically. It loads
bean instance only when client requests it, and instance is not in the
cache, or cached instance is older than read-timeout-seconds.
Prem Raghupathy <[email protected]> wrote:
This is a multi-part message in MIME format.
---=_newsgroups3c21148f
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Rajesh,
Thanks for your reply. I’m using WL6.1 sp1. When I log the methodcalls,
this is what I see on the server console.
SetEntityContext()
ejbCreate()
ejbPostCreate()
ejbLoad()
As you see, the ejbLoad() doesn’t get called every 5 sec, eventhough I
set the ‘read-timeout-seconds=5’ in the weblogic-ejb-jar.xml,
Do you have a working example for Read-Only BMP on WL6.1? The examplesdirectory
in weblogic 6.1 doesn’t have one.
Also find attached all the files. Any suggestions will be highly appreciated.
Thanks,
Prem.
Rajesh Mirchandani <[email protected]> wrote:
What version of the Server and Service pack are you using? Turn on
JDBC
logging and see if every ejbLoad() hits the DB.
prem wrote:
Hi All,
I have an Read-Only BMP that just read data from 20 tables and storesthem in a Collection. In a 'Read-Only' Entity bean, the ejbLoad() is
supposed to called periodically as defined by 'read-timeout-seconds'
parameter in 'weblogic-ejb-jar.xml'. But this doesn't happen. Every
time I invoke the EJB, ejbCreate() and ejbLoad() get called. Any suggestions
will be highly appreciated.
Here is the content of my 'weblogic-ejb-jar.xml' file.
<?xml version="1.0"?>
<!DOCTYPE weblogic-ejb-jar PUBLIC
'-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN'
'http://www.bea.com/servers/wls600/dtd/weblogic-ejb-jar.dtd'>
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>beanManaged</ejb-name>
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>1</max-beans-in-cache>
<read-timeout-seconds>5</read-timeout-seconds>
<concurrency-strategy>ReadOnly</concurrency-strategy>
</entity-cache>
</entity-descriptor>
<jndi-name>beanManaged</jndi-name>
</weblogic-enterprise-bean>
</weblogic-ejb-jar>
Thanks,
Prem--
Rajesh Mirchandani
Developer Relations Engineer
BEA Support
---=_newsgroups3c21148f
Content-Type: application/x-zip-compressed; name="C:\WebGain\bea\wlserver6.1\samples\examples\ejb20\basic\beanManaged\beanManaged.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="beanManaged.zip"
UEsDBBQAAAAIAJFMkisOCqPkpgMAALEKAAAJAAAAYnVpbGQueG1spVbbbts4
EH0v0H+YFYpFt7Ctxb42DuAYKprAToN1gPTNoKixw4SWBJJyYxT59w5JXRhH
chZbIA5kaq5nzhz6rFTFA3IDOdvhNMKH9J+/xynTgo9TZPmS5WyLWQQZblgl
zTRiUkZABpgJNY0m0fn7d+/fAZz9MR6DRgNbWaRMAoUtURmBGjaFAnMvNKSV
kBmMx+fOobY4AOZ7oYp8hzmFpy9RfGSwEZJKm0zi9g+f2K6UqCddmldeviFd
VIpjBHsmKxtkwMyV1lp9+OndnmN/3u+TCW16XNxx3MBimNpig67DLsMS80xP
Iy4J4BGIXJgR8GJXUptrGsAIHpjyD/SPj2wcaA1+YMrKsnPgUhBwAwlt7Ojc
B3ATmitkBmkc9BE7BG0IyGYk1tsdxAMufoA0eCJMoQ7krSpuKoVQER8gPTRV
eXeWZ3RQHpwvtS2Lgx0yPWquREkhNHVvChCmq2D3SPHBkevDT5fwOYpPvIyX
ye1sfHn9ZcDKjiOI4OspBkLUVmRnOWfpXBvWw+0MyETkXFYZ1lB/mjztZJvH
GeBTaOByHRmdxXWeprzY1ufZFvtJhvs19+haWgCXTGusAewbzkdiEa0hlkwx
I4r8r3bzXlAkIF7LlAe2Zxy04kfd28mZl6Np263RIF7PSRwmNsQI7OPXYtd8
vVEFR61Fvk2UKlTyxLG0pfnXHXLOL7m6cOfN9vXgsWSPCMySOM+YyhwutmsL
6qiuiJLB9+ViiH+9mNT7F+5qL0rKZvPqVBMtJnzWTkTXTkTXgYhSN6rFq1XQ
FsmWAmQ22PG/Ve5EgSgMvFtM3xxLiRtN//2dWd+grabRcPCeWd6cxEYWW8En
3o+U/HEaHUhsOwbrg2518REPgc89DT7Qx7vF+uu3ZfIc0p9KAylyej+uEbaQ
WvL9RzzJbnZzs7icz24vv12vnuNT2AeJXY8lM/fhvtrvKNFxxD6HVcdSpHHT
2lqXNuDngdfHyeLjbHbGe/bmmt8TrS0izt0v+l1yYYUqbra/W/di45iQ1Dcj
3GHqk83KcgJway9gzDWJtSZDZrz11QVwlkNKa8TtanoVv1rd6JMBTyqJv6He
FJMGnkBTku9rapAGup4vZqtVsuqsOnlZodpLNIHC9IpNN9eTqlMn6NGYF6Ow
QNEAUG0YxYI/wV+7QI12CuzPXo/mJFr1/f0/0JovLpPr21NQ/b4Sz111byD1
qjX7w6btKKOVIpkauNFfvg0v6yDFWVz/SqXnX1BLAwQUAAAACADSeJIrk74j
apABAACNAwAACwAAAGVqYi1qYXIueG1sjVLLbtswEDzHgP+BzcVAUXFdHwvG
AfwokqB5AE4OOQUUtbDpiqRAroPo70NKsuK8AB9nd2a4u0Nx/mJK9ow+aGfP
Tn/z8en5dDgYDsSPxe38/vFuyXCbZ1vp2d3D7N/lnA0HowxgtbPsWivvQh0I
TfjFLq3iAIv7BVtaQl95HZBdyWc5Q2kDm/AxwPJmlPQbouoPwDY2edhZrpyB
ggroXnqaPI15xKN2kK4aAWMCe+8sT75Nta1rqjuUcBRZaXCaWNfSyjUWAvpq
z9u4iPBFmqrEwGN/Mua5DFrxAyGfy4AXkSmg4fdqj8bRkXoBHfvdjKqUIRxn
sLyatRu0mt6mSuHFEKzCjOoKp+ngAj6V3wRem+w/1p1RE0Mp7ZqvyGu7jtL3
hIN145m9tDT9K8t2o30hJdVw4CCJBnyOS0RTNHlZZwUG5XVFzu9zVM6S1BZ9
lnyDVBT/5dsEBmnjih4fE/RJJ2rxTwGHsDeGD86ieT6TFE+S72JqN45Wu6py
npL/x+5++e/HF/D11mL/6yPrFVBLAwQUAAAACADbeJIr+q5g0iYBAAAqAgAA
FAAAAHdlYmxvZ2ljLWVqYi1qYXIueG1sfZBBTwIxEIXPkPAfKhcutrMe5GDq
EoE9YFCIYozHbjuBkt0uaYvr/nvbNUHFjeml+WbezJvHJx9lQd7ROl2Z2+EV
S4aTdNDnF/PVbPO2zkiNeVFttaS4z+leWLJ+mS4XMzLojyjANLsjz43zWLpL
sjCSAcw3c/KK+TKKyJglLCHZ/RQgexxF0c77ww1AXdcsR8FkVYJDGw1AXbhx
koDyCs63sgBHwVdwdl4KlJAf1Hi0B6sd0jDftNVQj81GlJhG+CCM2KLicKKD
fo8HpfYNVeik1Qdfxcm9E5ZC7tq+gCwKRb0usTp66lBWRrn0mkMn/5KEvzxa
i0Y21HkrPG6b9Cn0r0zRcOgst+vhfP+J/DLaHrk3Sndc+Y3bqOCfrPif5NvQ
4/sEUEsDBBQAAAAIADhNkiuTJ+0NxQUAAJMQAAAMAAAAU2VydmxldC5qYXZh
lVdfU9s4EH9nhu+wzcs5vdQpfbkrUKaBpiU3FBhIr3dPHcXeEFHZciU5kOn0
u99Klh05cUrPA4lj7e5v/++6YMlXdoeAjywrBOoY72evXsYzpnkSz5DlH1lO
5+nR/t7+Hs8KqQzcsyWLuYwnV+PHBAvDZX60dXhVmqI0t0YhyzZOVcbjG8yk
wV38peEiPpNCYLLr9FrJApXhqLtO/yZGqbpOJgYVq85ap49xzjKe3xFsbvDR
HHWfTnJuOBM7iDSqpUATL4wp4nP6uK0e/CrdDX4rUf8Pcl3IXGNoywPOhLyj
4C1MJuJTcv/XscAM80Bqm+YcWUqmPUHlIa8pGXaSGNUlp7LBBv2afrKZwCr4
V7N7ihLRDZ8/39+D5zBdcA3eVqBbBoWSd4ploHnGBVNgJJgFOuJjBguF8ze9
M8EJzmnQO3kqjeOK+njITpwUTx9XIouT1vcZE4LwAqVKTQYCy+HTzQXoMlkA
023WRKZ4YuN0OBwKmTCxkNoc/vHy5cGw1u0zzkZFMQy0Oh46tlCSu3/LSrOQ
CkYpKwymMFsBMV9Yjw9gkifxETB7RCWiIZHFSvG7hYEo6cPB69d/btPDiCy6
sUQaKHnIKnJJC+p4pk4CuNPxCG5X2mCmfwXxxSsytJNvJ/Jwf68oZ4InkAim
Nfg8o8gYzFMNQbrDd5vnAPa/yhkgzU9LLoiOgnI+/XgBBTl0AHNueSlXIHAz
LGSGA8+WUGUY1O7ccqdAwRIaMiQ/EK/MG/bfNCiXscCp6tWcJZRglRgv7G3B
bJoq/Abta7u2Nzn0zziq8q5ZsO6WGywd/diz7Lz43Fqn0JVZDpMrQKWkqtiG
9ssHZSl56tKfJxhtW2NNHnTpbC3rO3EEpOSDhg3tvleHREbtzbh+mpvpqsCo
Zzvr0NVz/6iiCocJyNLAG8d4hyY8iWryqhGB4UYgkfbGf51SGMF+vMh8Llyj
0pwSNE+wzrneUZVfUD+wzQ50QSJyfAgfRk50DacLq8mpTFeRNxkgZmnqO2Fk
mdtNtuIfwEG/llGQxqY+7fUGJLTfqLOehJBYZUohPJtRq9qTFaEbS5CYR6Ij
pdrjqnHQNuIpzqWyUSPXLZ3zKPnJb40mDQTTeE515IqJQKL6Qd+ixkLKr2UR
9YKy6+1GHc2pnp4EXXM7dCpUjZxK1IP3oWuu0MCmjH6IrJpxVexRf+AExK7T
hFqt76rFAZYk3MPY2FquyTsddfM8bZPn33Lm+o7Po2XM9TgrDGVRvw5qYPoW
kM/Hw0O4lE5ZAk2kSrUHx/TZsy3EttAfgIL4CKwtOkg4ahC5pHZsFeuUVi9U
wG1ZkhH+d7TO3/rydZnwdEPGw4JTpUacxjjTly5T++u8bus2yTVP0cOShp1K
2YtgbIpUoH2Sndcl0BZ404QKq0ca5kpmUBviATbFbwPuCo9L2sk7uuvB76RV
l8I/gqDUbhsOidXYJSNfQdP8dXX4g0JuzyJahGke2cVkbFt402ShwH7YG9ra
fSJnFBRi2wkbAeAkODWJO1SzQVuL/5n0w9YFAZhDgMPNayuIGDuJt4beT6aK
Jm60VoWGO43q1W74MU3zcOnzoYjjuIXTOJoauHRzJKKv+pRu47ko9cIje+pg
8bDL5XpfzamBZi4j/W4QjlGf+dRKvC4TIo8aD1LBlipvBlUwjzpwr62tdlHR
2s4n2olndsCiCnG1IVUS65cldb5qjLec5DXyUgYbI2/n6K41/pWZF758UEHv
Imu9NkReof4Op39A4zYWXg022kGriUfOd502KZUiMbSpoxrQMqj1A7VEt9+V
Smxsbd7tW5cflzXZT/cuweitcO2eYLHy7DsvssItXWSLTQzTDIsQvRXMKpfq
Id8x3uuAbYVr/bYM9TqzftSUVhHbGvDS4snlZDoZXXw5u7qcjv+Zfnk/Opte
3fw7WFddr3n/u89THn++aOvzntlZumrmv3e3Bd9QvGiiTX//AVBLAwQUAAAA
CAC9dl0ruSRzDGQBAADYAgAAHQAAAFByb2Nlc3NpbmdFcnJvckV4Y2VwdGlv
bi5qYXZhlZJPT+MwEMXvlfod3rFUbFo4gbjwRz2stCshOHCeONPGS2JbM5Nt
K8R3x0mDioRYtFGUOPGb37x5ciL3TBsG76hNDWvBf8rzZVGSeleUTOE3hbxf
XU0n08liPp9OMMe9RMeqPmxWIlFWO8fJfAzwCqslbvNqnVcMR03DAjLjNpkO
1Rax9VZXQlu0UTgLKYDgWIx8QBJWNjS+9Ya1xHYgkXOxC1b0iAFzTZ3VUXAX
0178pjbM3AnOLi8vUO7xxOWvuPHuFD+DK3DTNHjoRYqHTJe/XBXfUH6cL5dn
Pep2dYPHveYJ9BvaYjpJXdl4B9eQ6tc58c44VIrjn5c+X+CQMLKxOzJXs2bp
KNEhtdhZjkoTO7/2XEFNMv5Qc3gu+tdo4ysDsxO8vH7qmHuYdM70EHhKEpN4
Mj6aGDwM2/+ygOtEQi3a3Ls/XMfrcdB+mHuU/If1ETEW5kG0Syyz9++rPFe+
3wBQSwMEFAAAAAgAUE2SK2gMv9fQAQAArgQAAA0AAABDYXNlSG9tZS5qYXZh
lVTBbtswDL0b8D8QPbVBoQy79rK1aFFsGFBs+wHFphN1lmRQdJNg2L+PkuXM
Te0N08FJZL5HvseHdLr6obcIeNC2azEofN68f6c2OphKbVC7L9rJ+/qmLMrC
2M4Tw7N+0YdYqO4INeP9ocKOjXc3MyX3n24fvcW5Vw/G1UgLaEXWqK9o/SK/
6tm0apUmW69WZQEr+L4zAYxjpEZXCPKDdwg7GWBy23hK1zKaCIQ7HVC+XieC
FiXRddvWlNNMLEo6hCjGF0dIOuCn7E9wDAAjCNY5J2vofJEGDofAexTUxE
uDbWGJfuo9eZ4SJPpKLKC3XiReg0aYEhQUAO4JsE5b3PZAE0idIaHZtKtwpg
AA/PdfzIymILqNIgl1fCQn4f4Gyd1/DW/9daPzKj7TiJa2SbU1v3hnegYWte
0METGavpCJ/xCA15m/GxvEMKJoipDIE9SdjUdGj4kERDNzBEgny+MRm3nVKP
CELuycGbE0WPNTiKOqtZjGcGLh6TlkEpdCIfiSRm0ZQ45NmG/9p9Lvn/1Vxi
Z23vJAERKjGRuBzFYRug0abt6WRCQJyl+9e/gcoJXchVVH17fDpt7DKv6s8O
r4ZgjsE7s3o+eL/K4jdQSwMEFAAAAAgAu16TK34dDI8hCAAAVSIAAAwAAABD
YXNlRUpCLmphdmHtWVtz2zYWfo5n/B+weimVOPS2j3bS2frWOpt1Xavb7j51
IPLYgkUCDADKVnf83/ccALxLCj1tpulMOZOIJg7O/fKBLHiy5HfA4JHnRQYm
hvv5V3+P59yIJJ4Dl//iEtfT4/29/T2RF0pbds9XPBYqnoEWPBO/8nkGx91V
8yGLX/aelVZk8anKMkisUHLT6k+4pHRf1iMpFZ9q4BbOHxMohts9yVlZZCJB
qn/Ceifh+buT3evSCrs+QfO3r54qaeHRbiK4EDIFvVPClZqVycJz2kn4/fwe
nXKl7IUqZbqVVPJcyLv4UgqLMdmiWyC6cj9tVt1Q6FzEN5Crrd72wbrWqgBt
BZhhwIKkLXqQgGv8kxLHC/JWOj77e4cvX+7vsZfslBvASDFhGJesiUlMq4f7
e0U5x3CzJOPGNMSUxjlIa1o72P+IL2O3QvKMGcst7iu0WGGusLlSGdH8dH5z
8v3snL1lVpdw7HdURJ2Ys8Q+HrdXZ1ajuYwnCQbJXqbH7PCQ8cwoZhdAVDnX
a4ZZ2d7kk52tOpxQgvT1wRL895bJMsscBf3znmHomxmggcS8q9gtMnRP31WO
QuKw5R8F1zwn3Vn36rDwxIdOJ+/flRIpM2A7ZNHAIVNyMrHL1F006dOzhGPh
p5PpsSc6PJytjYU8VqWN0XhpMxlNhDQihTHCakZ2IUxMNr2to/LkQ9c469/S
PMNdA9tLOVCoa+yQYJydmxhvMqzOgYFlN/ChFBpSNl9XhjBTQCJuqQ9iFh04
PiwHu1ApVZJUlpUG0sDA7cPHof9vcwF2om8wKylFe7a3Vlg0YewVm0zHWR+o
Bjb92FVYbzBx1jGxMqW0bQOfYdo1NpAtttVLZNxvt+294qlppRy71Sr3TQK0
EchPWuxPSuPM7VUvVL2Yda+PzJSwfeslbp14GvWV925p0jAh3ULKsU1jbx2v
Rnu4jpOuwfV47Hh5XsoQVsOwOI1zsWG3XGSlhjqEvQCSW33sutGj50chLUfH
rubnyP2Gaw3YPSGd4ehw04UVpl2Y21h+2b+a8saBEHKNhVZ/B7Zp/9FuXb8a
XMjZM6uYOg2RM25yyte6U3cmEIY92cAv6EGXhPRHrV3DI4ZHSEoLP5Sg11F/
/QZMmVkcRkyTNCRHI+qHA/IV+Qwewuirl1k1QIslPtls8AXpWIfm6IidAHZv
YIhBJG29mQ0c8LAQGdatNrF0rdUlyDjuhCbY5RmWvHYmef2iL6eVjEYKOmmJ
ZvXojpvlVczT9NyDkqhYNktPY7VZxUb8CnQ3eVXdN2z87xMG0CYLFtW1x8wH
eIbJ5/8J+yZt5ZGH34LZkyx/1DyBVthcnc1+eF/LPGLUJUlwTWMXWj24qLcb
A4taRE8emGXtiiBIVhZRQiOsMDWlL8hBX51hOkGnsYb29VdbfU5bHUxG59fh
VHSP++P+yaP3baM8URpDVChJA9AD48Qd6epZ7z2zUDnqjWhI32KyBUYTKsjv
cCUmh0zimj9GmFAtIDlzIE95x9sHFfiiB8gRKaYAuiCL2c8L8JKSTFBeEDI1
geGbRKXwdS3MKxhN3xy65wd+G0I1LiQKxI2KjpvufILTw3JZa+z0QOtdBnAM
vBPTEoDxpLiedkVUlr0pvg53FxgvYvI69yfxJqUTOAj8hnwQNtlSy8ouXh9C
lrA+QOCZiSV4a6jTobK1VZWcsLMj7cEnla24I1/KlF5J+cVhVoYmf909Do3L
/t7p/3kFUGiFJ83c5xupUJXmePkbXy2M0IJXSU6KWCy6wmIIS+OOixtcsfXi
GfJJ13+S/hFC3cpLPwfwnD4MZLu5DCuDtXD3i48BN+/sANxeENfdyO2ToLY/
BLFtx2qjUdrvgs+qeH8qhNbw/zwwWqPPNpS2A5mNY/xnQWYvQuOfmEkDCGgt
NIXwwosKBkN3eWYaYEHXNk+H6m5vm2wKcZC+akNFuv3kb0uG7a9+saCMrRtg
D0M1axuBVFvvMyx+C3+9N2iu3w3g0uvn1Ybo+Ocfjcw3fqQ7RIuVkrZD9CDs
ApW7EyvEm61J72IX9o+KoH9vix2sd23HU58CgW35EPGxSLkmI6t0Ca5JuKSE
mYPPmc80RxoQQx90TtbBbei1qJ6HU582Adzs8FEvv/oc/etFjHHnHeMoau/D
ek/VhIvlZHPOfkvHpKTE0xgdfprvDdWhrHlSKJWNxPYNBPrsgjn8stKDbFX0
2uOyFbLuNzXsb8Kedl/L17jQ/0HXGUrFE2K+DjdvWeTvpuyUvlfFCI2u8Nwa
TR5gjmEWSXyfzpPYudxTTqaIih4uw7HSzfYX1YitGcchXNGEth9VzI6IzxE2
k2v8nRw4VT0Dr2LAJC1IIqE1jF3eXaArcVZiWmRKLcuCvTs7OWVn2NeNKnUC
MbtGKIAYLFVYL5g4C0iW6EtuWzjFcaK0end1dskkWsxSwE4J9aDQ4Nm9TsEk
Wnhtwim+zwgz5gvDKiNfYxK9vuc6fswz7L6ZSw7aZkgM9/eN3D6z6uNPY1Fb
tTU+oVq4FXfEP27t3oybIrkLNXUODpTOUZVHf/OJNK0SK04yZdpQropV77Nt
N2KVg7RGq4gDtafEp6yHfrKF/EbY4BpH/fPU/RrqpmcFBLufLA82nrhqTTt+
wKKO8MxTewAPJl3jN0DnQZp2TR4IR+NfjcC8TeyqKh5oSse9WlU6pf1WXRvH
+QiNVXMYF/rc/F9VslzcLaz/8IwKEmzW4V3DzzB/TzWD5YOaMAN6Jfy7qk5M
Scsw25qYkfHh4/iUbUDopgWO3H//B1BLAwQUAAAACACPSpIrm/ShfEkBAACo
AgAACQAAAENhc2UuamF2YXWS0UvDMBDG3wv9H+5Ri2Ti6150bsgEEUR8v2a3
NrNJSnLVifi/e2m7zTmWQgN3X75+90tb1O9YEdAWbdtQVLQpb65VidFoVRK6
J3TSX03zLM+MbX1g2OAHqmCNeiHrmRZbTS0b76ZHim2yUovH2XO5Ic3HTdWx
aVTRu06KIs+ggNeawBLXfhXBOODapJ0prFETYCApEbRd2RgNfc2v4U5r3zme
SVK1d4mmcshdoJgk/Mc3uZgVOTYaG2AvTR9pp0rzXkFvQ/1QUsX0oniw4Dr4
T8CzFPoYkzwbgx4muMeYODM5cdlzge/EAGCgAPLpB2LAphn0y3lUQ33s3gaS
yRycrDcx86E/tZzvxLRL9U98Lvx47uwyPagEUViC9tZ2TlCmo8I6QPyKTDbK
9ZhG+A92Bxhjxop4iBkvLgeeEU7/JZCb+Elw0vMLUEsBAhQAFAAAAAgAkUyS
Kw4Ko+SmAwAAsQoAAAkAAAAAAAAAAQAgALaBAAAAAGJ1aWxkLnhtbFBLAQIU
ABQAAAAIANJ4kiuTviNqkAEAAI0DAAALAAAAAAAAAAEAIAC2gc0DAABlamIt
amFyLnhtbFBLAQIUABQAAAAIANt4kiv6rmDSJgEAACoCAAAUAAAAAAAAAAEA
IAC2gYYFAAB3ZWJsb2dpYy1lamItamFyLnhtbFBLAQIUABQAAAAIADhNkiuT
J+0NxQUAAJMQAAAMAAAAAAAAAAEAIAC2gd4GAABTZXJ2bGV0LmphdmFQSwEC
FAAUAAAACAC9dl0ruSRzDGQBAADYAgAAHQAAAAAAAAABACAAtoHNDAAAUHJv
Y2Vzc2luZ0Vycm9yRXhjZXB0aW9uLmphdmFQSwECFAAUAAAACABQTZIraAy/
19ABAACuBAAADQAAAAAAAAABACAAtoFsDgAAQ2FzZUhvbWUuamF2YVBLAQIU
ABQAAAAIALtekyt+HQyPIQgAAFUiAAAMAAAAAAAAAAEAIAC2gWcQAABDYXNl
RUpCLmphdmFQSwECFAAUAAAACACPSpIrm/ShfEkBAACoAgAACQAAAAAAAAAB
ACAAtoGyGAAAQ2FzZS5qYXZhUEsFBgAAAAAIAAgA4wEAACIaAAAAAA==
---=_newsgroups3c21148f----
Dimitri
Dimitri

[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.

Entity Beans Cache

Hi,
We are running our application on WL platform 7.0. We have a number of EntityBeans(about
30-40) which are container managed and also use CMR.
The max-beans-in-cache is at its default of 1000. We reach this limit of 1000
for about 10-15 of these beans in a day or two after a restart of the server.
(This is production server, we restart this occasionally for maintenance). The
memory usage for the server keeps increasing and once the entity cache limit is
reached we see that passivation keeps occurring and the heap usage is always at
about 80%-95% of the maximum (Total heap size is 1.5GB). We assume this could
be due to the EntityBeans that are cached by WebLogic. We also see performance
problems occassionally that might be probably due to the GC or passivation.
We want to lower our memory usage and also get rid of the occassional slow response
time. For doing this, is there any way to flush out those Beans from EntityCache
which are no more used ? WebLogic doesn't seem to flush the cache but only passivate
them as and when new beans are required. Is there any setting to change this behaviour
Cheers
Raja V.

Thanks Thorick,
We are using Database concurrency and non-read only beans, hence i believe this
patch must help us.
secondly, are you aware of any way to find out the memory usage of the default
WLS Entity Bean Cache ?
Cheers
Raja
"thorick" <[email protected]> wrote:
>
Hi,
If you are using 'Database' concurrency, then support for an idle-timeout-seconds
on this cache will be coming in release 7.0sp5. This feature is intended
to ease
heap usage when Entity Beans using Database/Optimistic/ReadOnly (but
NOT Exclusive
or read-only !). One sets the max-beans-in-cache to be large enough
to handle
periodic
or occasional peak loads and idle-timeout-seconds is set to free the
cache of
unused beans
during periods of low demand.
If you cannot wait for sp5 and are willing to run a patch, there are
patches available
for
7.0sp2 and 7.0sp3. You'll have to contact your support representative
about
these.
Refer to 'CR110440' courtesy of yours truly !
Hope this helps
-thorick

Exposing local entity beans to web tier?

Hello all,
I have a question concerning basic design issues with EJB and the JSP presentation
layer. Currently, I have designed a system using all local component interfaces
of EJB 2.0. I currently have the following architecture in place:
EJB --> Servlets (WebWork Actions) --> JSP
I'm utilizing the session facade design pattern where the business logic in encapsulated
in session beans, which internally access the entity beans, etc. However, I am
doing something of the following:
sessionBean.getUserAccounts() which returns a Collection of actual UserAcountLocal's.
I then am passing this collection off to the JSP just to cycle through each entity
bean and display the data via its getXXX() methods. No modifications to the entity
beans are being done directly in the Actions/JSPs, rather they are modified through
methods of the session beans. Now I know that there is the concept of DTO (Data
transfer objects), which send the data from the particular entity bean to a regular
java bean for presentation. I know that DTO's increase performance if one is using
remote interfaces, because there is less network traffic that occurs via that
transport method. However, I know that WebLogic performs excellent caching of
entity beans, so that multiple invocations of get() methods on entity beans will
not make a trip to the database each and every time the get() method is called.
So, my question is: Is it "safe" to continue with the current way I am designing/coding
the system? I just find it a bit tedious to create value objects for each and
every entity bean, if I know that I will not be calling setXXX() methods from
within the presentation layer. Also, with EJB 2.0 and the introduction of local
component interfaces, it seems that issues regarding limiting the amount of network
traffic don't seem to be so relevant. Any suggestions/tips are appreciated. :-)
Best regards,
Ryan LeCompte
[email protected]
http://www.louisiana.edu/~rml7669

use dtos
the main reason is that if you call a getXXX() method on a local or remote
interface from your servlet then that bean is retrieved again (as the
servlet is outside the transaction involved in the initial retrieval)
For example if you retrieve 100 users and want to display them in a html
table with the user id, first name and lastname then there end up being more
than 300 SQL statements executed (this is unless your ejbs are readonly)
If you have a tool (like sql server profiler) that traces sql statements i
recommend you use it to see the staggering amount of sql statements that are
being executed by your current code - then DTOs will look much more
appealing (it worked for me) :).
I would also recommend using dtos when performing updates. Basically work
towards your servlets never directly accessing anything entity bean related.
Some people extend this further and have the DTO as the single argument in
the create method of an entity bean - I havent done this yet myself but it
looks like a good idea to me.
"Ryan LeCompte" <[email protected]> wrote in message
news:[email protected]...
>
Hello all,
I have a question concerning basic design issues with EJB and the JSPpresentation
layer. Currently, I have designed a system using all local componentinterfaces
of EJB 2.0. I currently have the following architecture in place:
EJB --> Servlets (WebWork Actions) --> JSP
I'm utilizing the session facade design pattern where the business logicin encapsulated
in session beans, which internally access the entity beans, etc. However,I am
doing something of the following:
sessionBean.getUserAccounts() which returns a Collection of actualUserAcountLocal's.
I then am passing this collection off to the JSP just to cycle througheach entity
bean and display the data via its getXXX() methods. No modifications tothe entity
beans are being done directly in the Actions/JSPs, rather they aremodified through
methods of the session beans. Now I know that there is the concept of DTO(Data
transfer objects), which send the data from the particular entity bean toa regular
java bean for presentation. I know that DTO's increase performance if oneis using
remote interfaces, because there is less network traffic that occurs viathat
transport method. However, I know that WebLogic performs excellent cachingof
entity beans, so that multiple invocations of get() methods on entitybeans will
not make a trip to the database each and every time the get() method iscalled.
So, my question is: Is it "safe" to continue with the current way I amdesigning/coding
the system? I just find it a bit tedious to create value objects for eachand
every entity bean, if I know that I will not be calling setXXX() methodsfrom
within the presentation layer. Also, with EJB 2.0 and the introduction oflocal
component interfaces, it seems that issues regarding limiting the amountof network
traffic don't seem to be so relevant. Any suggestions/tips areappreciated. :-)
>
Best regards,
Ryan LeCompte
[email protected]
http://www.louisiana.edu/~rml7669

Questions about entity bean caching/pooling

We have a large J2ee app running on weblogic6.1 sp4. We are using entity beans
with cmp/cmr. We have about 200 EntityBeans and accessed quite heavily. We are
struggling with what is the right setting of max-beans-in-cache and idle-time-out.
The current max heap setting is 2GB. With the current setting (default setting
of max-beans-in-cache to 1000, with a few exceptions to take care of cachefullexceptions)
we run into extended gc happening after about 4 hours. The memory freed gradually
reduces with time and lurks around the 30% mark after about 4 hours of run at
the expected load. In relation to this we had the following questions
1. What does caching mean?
a. If a bean with primary key 100 exists in the cache, and the following
is done what is expected
i. findByPrimaryKey(100)
ii. findBySomeOtherKey(xyz)
which results in loading up bean with primary key 100
iii. cmr access to bean with
primary key 100
Is the instance in the cache reused at all between transactions?
If there is minimal reuse of the beans in cache, Is it fair to assume that caching
can only help loading of beans within a transaction. If this is the case, is there
any driver to increase the max-beans-in-cache other than to avoid CacheFullException?
In other words, is it wrong to say that max-beans-in-cache should be set to the
minimum value so as to avoid CacheFullExceptions.
2. Again what is the driver of setting idle-time-out to a value? ( We currently
have it at 30 secs) Partly the answer to this question would again go back to
what amount of reuse is done from cache? Is it right to say that it should be
set to a very low value? (Why is the default 10 min?)
3. Can you provide us any documentation that explains how all this works
in more detail, particularly in relevance to entity beans. We have already read
the documentation from weblogic as is. Anything to give more explicit detail?
Any tools that can be of use.
4. What is the right parameter (from among the things that weblogic console
throws up) to look at for optimizing?
Thanks in advance for your help
Cheers
Arun

The behaviour changes according to these descriptor settings: concurrency-strategy,
db-is-shared and include-updates.
1. If concurrency-strategy is Database, then the database is used to provide locking
and db-is-shared is ignored. A bean's ejbLoad() is called once per transaction,
and the 'cache' is really a per-transaction pool. A findByPrimaryKey() always
initially hits the db, but can use the cache if called again in the same txn (although
you'd simply just pass a reference around). A findByAnythingElse() always hits
the db.
2. If concurrency-strategy is ReadOnly then the cache is longer-term: ejbLoad()
is only called when the bean is activated; thereafter, the number of times ejbLoad()
is called is influenced by the setting of read-timeout-seconds. A findByPrimaryKey()
can use the cache. A findByAnythingElse() can't.
3. If concurrency-strategy is Exclusive then db-is-shared influences how many
times ejbLoad() is called. If db-is-shared is false (i.e. the container has exclusive
use of the underlying table), then the ejbLoad() behaviour is more like ReadOnly
(2. above), and the cache is longer-term. If db-is-shared is true, then the ejbLoad()
behaviour is like Database (1. above).
Exclusive concurrency reduces ejbLoads(), increases the effectiveness of the cache,
but can reduce app concurrency as only one instance of an entity bean can exist
inside the server, and access to it is serialised at the txn level.
You can't use db-is-shared = false in a cluster. So Exclusive mode is less useful.
That's when you think long and hard about Tangosol Coherence (http://www.tangosol.com)
4. If include-updates is true, then the cache is flushed to the db before every
non-findByPrimaryKey() finder call so the finder (which always hits the db) will
get the latest bean values. This overrides a true setting of delay-updates-until-end-of-tx.
The max-beans-in-cache setting refers to the maximum number of active beans (really
beans that have been returned by a finder in a txn that hasn't committed). This
wasn't checked in SP2 (we have an app that accidently loads 30,000 beans in a
txn with a max-beans-in-cache of 3,000. Slow, but it works, showing 3,000 active
beans, and 27,000 passivated ones...).
This setting is checked in SP5, but I don't know about SP4. So you do need to
size appropriately.
In summary:
- The cache isn't nearly as useful as you'd like. You get far more db activity
with entity beans than you'd like (too many ejbLoads()). This is disappointing.
- findByPrimaryKey() finders can use the cache. How long the cache is kept around
depends on concurrency-strategy.
- findByAnythingElse() finders always hit the db.
WebLogic 8 tidies all this up a bit with a cache-between-transactions setting
and optimistic locking. But I believe findByAnythingElse() finders still have
to hit the db - ejbql is never run against the cache, but is always converted
to SQL and run against the db.
Hope this is of some help - feel free to email me at simon-dot-spruzen-at-rbos-dot-com
(you get the idea!)
simon.

Entity bean (ejb 3.0) refactoring problem

I didn't find a better method than regenerating an entity bean after modifying the table definition and renaming the class after deleting the old one.
I'm not sure i can delete the old class representing the entity bean before regenerating it without any effects into the others entity beans.
It work fine but still a little problem. The refactoring process didn't change the name of the entity bean into the select clauses into queynamed injection.

I am facing a similar problem. Does JDeveloper 10g (10.1.3.3.0) provide an automatic process to update an Entity Bean definition when the underlying database table definition changes?
I also noticed that for JDeveloper to create all the relationships (i.e. @OneToMany, @ManyToOne) between multiple Entity beans, I need to create all the Entity beans together in one pass using the wizard. If two entities depend on each other, and not created together, JDeveloper will not create the relationships between them. Is there a way around that?
Thank you

Error While Deploying A CMP Entity Bean With A Composite Primary Key

Hello all,
I have a problem deploying CMP Entity beans with composite primary keys. I have a CMP Entity Bean, which contains a composite primary key composed of two local stubs. If you know more about this please respond to my post on the EJB forum (subject: CMP Bean Local Stub as a Field of a Primary Key Class).
In the mean time, can you please tell me what following error message means and how to resolve it? From what I understand it might be a problem with Sun ONE AS 7, but I would like to make sure it's not me doing something wrong.
[05/Jan/2005:12:49:03] WARNING ( 1896):      Validation error in bean CustomerSubscription: The type of non-static field customer of the key class
test.subscription.CustomerSubscriptionCMP_1530383317_JDOState$Oid must be primitive or must implement java.io.Serializable.
     Update the type of the key class field.
     Warning: All primary key columns in primary table CustomerSubscription of the bean corresponding to the generated class test.subscription.CustomerSubscriptionCMP_1530383317_JDOState must be mapped to key fields.
     Map the following primary key columns to key fields: CustomerSubscription.CustomerEmail,CustomerSubscription.SubscriptionType. If you already have fields mapped to these columns, verify that they are key fields.Is it enough that a primary key class be serializable or all fields have to implement Serializable or be a primitive?
Please let me know if you need more information to answer my question.
Thanks.
Nikola

Hi Nikola,
There are several problems with your CMP bean.
1. Fields of a Primary Key Class must be a subset of CMP fields, so yes, they must be either a primitive or a Serializable type.
2. Sun Application Server does not support Primary Key fields of an arbitrary Serializable type (i.e. those that will be stored
as BLOB in the database), but only primitives, Java wrappers, String, and Date/Time types.
Do you try to use stubs instead of relationships or for some other reason?
If it's the former - look at the CMR fields.
If it's the latter, I suggest to store these fields as regular CMP fields and use some other value as the PK. If you prefer that
the CMP container generates the PK values, use the Unknown
PrimaryKey feature.
Regards,
-marina

Multiple create methods of entity beans in single transcation

Hi,
I have some entity beans with CMR. I am managing these entity beans with a Stateful session bean whose transaction type is Container Managed for all its methods.
In one particular method of this Session bean I am calling two entity bean's create method. i.e I am creating two entity beans through home.create() methods. There are two home.create() methods one after another inside a try catch block.
I want that the entire operation be under just one transcation so i have also given the transaction attribute as Required for all methods of Session bean and Entity Beans.
However if i pass invalid parameters to second create method so that it generates exception then still the first create statement is successful and database is updated.
what i want is that the first create also should be roll backed.
How can i acheive this through Container Managed Transaction Session Bean?

Hi Ashwini,
"Ashwini" <[email protected]> wrote in message news:400291af$[email protected]..
I have some entity beans with CMR. I am managing these entity beans with a Stateful session bean whose transactiontype is Container Managed for all its methods.
>
In one particular method of this Session bean I am calling two entity bean's create method. i.e I am creatingtwo entity beans through home.create() methods. There are two home.create() methods one after another inside a try catch
block.
>
I want that the entire operation be under just one transcation so i have also given the transaction attribute asRequired for all methods of Session bean and Entity Beans.
>
However if i pass invalid parameters to second create method so that it generates exception then still the firstcreate statement is successful and database is updated.
what i want is that the first create also should be roll backed.
How can i acheive this through Container Managed Transaction Session Bean?o Do you use TXDatasource with your entity beans?
o In CMT transactions are automatically rolled back only when RuntimeExceptions
are thrown. What kind of exception is thrown in your case?
Regards,
Slava Imeshev

Timeout of session / entity bean

Hi all
We are facing "RollbackException: The transaction has been marked for rollback (timed out)" excpetion. please help us in resolving this.
Here is problem description.
Code Description:
Step1: Action class calls Session bean
Step2:Session Bean does three things
A. Reads various value from database and write it to fileOutputStream
B. Generate a Sequence number using Sequence
C. Call create method of Entity Bean by local reference to insert the created file (in step 2A) in database as blob
As per our observation session bean takes around 20-30 sec in processing 2A and 2B.
But at 2-C, code raises following error
TariffDocumentBlob is the Entity Bean
TariffSessionEJB is the Session Bean
javax.ejb.CreateException: Error creating EntityBean: RollbackException: The transaction has been marked for rollback (timed out)
05/10/24 16:04:01      at TariffDocumentBlobLocalHome_EntityHomeWrapper397.create(TariffDocumentBlobLocalHome_EntityHomeWrapper397.java:1135)
05/10/24 16:04:01      at com.derc.rims.businessservice.businessinterface.TariffSessionEJBBean.createTariffBlobMasterRecord(TariffSessionEJBBean.java:102)
05/10/24 16:04:01      at com.derc.rims.businessservice.businessinterface.TariffSessionEJBBean.uploadTariff(TariffSessionEJBBean.java:76)
05/10/24 16:04:01      at TariffSessionEJBLocal_StatelessSessionBeanWrapper96.uploadTariff(TariffSessionEJBLocal_StatelessSessionBeanWrapper96.java:80)
05/10/24 16:04:01      at com.derc.rims.businessservice.businessinterface.BISessionFacadeEJBBean.delegate(BISessionFacadeEJBBean.java:534)
05/10/24 16:04:01      at BISessionFacadeEJB_StatelessSessionBeanWrapper4.delegate(BISessionFacadeEJB_StatelessSessionBeanWrapper4.java:101)
05/10/24 16:04:01      at com.derc.rims.action.tariff.CalculateTariffAction.execute(CalculateTariffAction.java:75)
05/10/24 16:04:01      at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
05/10/24 16:04:01      at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
05/10/24 16:04:01      at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1485)05/10/24 16:04:01      at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:527)05/10/24 16:04:01      at
javax.servlet.http.HttpServlet.service(HttpServlet.java:760)05/10/24 16:04:01      at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)05/10/24 16:04:01
at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)05/10/24 16:04:01      at
oracle.security.jazn.oc4j.JAZNFilter.doFilter(Unknown Source)05/10/24 16:04:01      at
com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:649)05/10/24 16:04:01      at
com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:322)05/10/24 16:04:01 TRANSACTION OVER05/10/24
16:04:01      at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
05/10/24 16:04:01      at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
05/10/24 16:04:01      at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
05/10/24 16:04:01      at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
05/10/24 16:04:01      at java.lang.Thread.run(Thread.java:534)
com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: timed out     at
BISessionFacadeEJB_StatelessSessionBeanWrapper4.delegate(BISessionFacadeEJB_StatelessSessionBeanWrapper4.java:159)
at com.derc.rims.action.tariff.CalculateTariffAction.execute(CalculateTariffAction.java:75)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1485)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:527)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
at oracle.security.jazn.oc4j.JAZNFilter.doFilter(Unknown Source)
at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:649)
at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:322)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
at java.lang.Thread.run(Thread.java:534)
     Nested exception is:java.rmi.RemoteException: No Exception - originate from:java.lang.Exception: No Exception - originate from:; nested exception is:
     java.lang.Exception: No Exception - originate from:     at com.evermind.server.ejb.EJBUtils.makeException(EJBUtils.java:931)
     at BISessionFacadeEJB_StatelessSessionBeanWrapper4.delegate(BISessionFacadeEJB_StatelessSessionBeanWrapper4.java:159)
     at com.derc.rims.action.tariff.CalculateTariffAction.execute(CalculateTariffAction.java:75)
     at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
     at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
     at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1485)
     at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:527)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
     at oracle.security.jazn.oc4j.JAZNFilter.doFilter(Unknown Source)
     at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:649)
     at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:322)
     at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
     at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
     at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
     at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
     at java.lang.Thread.run(Thread.java:534)
     Caused by: java.lang.Exception: No Exception - originate from:     at com.evermind.server.ejb.EJBUtils.makeException(EJBUtils.java:930)
     ... 17 more
We have tried out .....
- Making new Enity Bean
- changing timeout of session bean by changing it in properties
<session-deployment name="TariffSessionEJB" timeout="300" >
We are using Oracle 10g application Sever and Oracle 10.1 database.

Assuming you are using either 9.0.4 or 10.1.2, please note that default transaction time out is 30s and you can change that <transaction-config> element in server.xml. This is specified in millliseconds
-Debu

How do I create an Entity Bean with unknown primary keys

Hi,
Can a good folk help me.
I am mapping an entity bean to an oracle table for the purpose of logging . I do not need a primary key contraint on this table. How do I specify in my entity bean file descriptor not to use any field for primary key ...
I have done this so far...
in my ejb.xml file - I set....
<prim-key-class>java.lang.Object</prim-key-class>
and deleted ....
<primkey-field>...</primkey-field>
My table structure is .....
CREATE TABLE FAMS_REQUEST_LOG (
EDITEDBY VARCHAR2(20),
OLDTRANSDATE DATE,
REQUESTID VARCHAR2(30) NOT NULL,
OLDQTY NUMBER(20),
NEWQTY NUMBER(20),
NEWTRANSDATE DATE)
but I still get this error message on deploying...
[#|2006-03-01T14:30:29.250+0100|INFO|sun-appserver-pe8.1_02|javax.enterprise.system.tools.deployment|_ThreadID=19;|Total Deployment Time: 11000 msec, Total EJB Compiler Module Time: 0 msec, Portion spent EJB Compiling: 0%|#]
[#|2006-03-01T14:30:29.265+0100|SEVERE|sun-appserver-pe8.1_02|javax.enterprise.system.tools.deployment|_ThreadID=19;|Exception occured in J2EEC Phase
com.sun.enterprise.deployment.backend.IASDeploymentException: Fatal Error from EJB Compiler -- JDO74046: JDOCodeGenerator: Caught a MappingConversionException loading or creating mapping model for application 'fixassetenterpriseapp' module 'FixAssetEnterpriseApp-EJBModule': JDO71030: There is no column in table FAMS_REQUEST_LOG which can be used to support the servers implementation of unknown key classes.
at com.sun.ejb.codegen.CmpCompiler.compile(CmpCompiler.java:274)
at com.sun.ejb.codegen.IASEJBC.doCompile(IASEJBC.java:615)
at com.sun.ejb.codegen.IASEJBC.ejbc(IASEJBC.java:563)
at com.sun.enterprise.deployment.backend.EJBCompiler.preDeployApp(EJBCompiler.java:340)
at com.sun.enterprise.deployment.backend.EJBCompiler.compile(EJBCompiler.java:209)
at com.sun.enterprise.deployment.backend.AppDeployer.runEJBC(AppDeployer.java:284)
at com.sun.enterprise.deployment.backend.AppDeployer.deploy(AppDeployer.java:176)
at com.sun.enterprise.deployment.backend.AppDeployer.doRequestFinish(AppDeployer.java:107)
at com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(J2EECPhase.java:146)
at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:71)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:633)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:188)
at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:520)
at com.sun.enterprise.management.deploy.DeployThread.deploy(DeployThread.java:143)
at com.sun.enterprise.management.deploy.DeployThread.run(DeployThread.java:172)
|#]
Dotun

you will have to create a sequence and a trigger
CREATE SEQUENCE <SEQUENCE NAME>
INCREMENT BY 1
START WITH 1
NOCACHE
/this sequence will guarantee that each requested number is unique
the trigger will select from this sequence and insert the obtained value in the new record
CREATE OR REPLACE TRIGGER <TRIGGER NAME>
BEFORE INSERT ON <TABLE NAME>
REFERENCING NEW AS NEW OLD AS OLD
FOR EACH ROW
    BEGIN
        select
            <SEQUENCE NAME>.nextval
        into
            :NEW.<COLUMN NAME>
        from
            dual;
    END;
[/CODE]
this will always take the value from the sequence, even if you already provided a value yourself
(otherwise you will first have to test if :NEW.<column name> is null, but I wouldn't do this for a key column.
if you need the generated key back for further processing (inserting it into a child table for example), you can use the returning clause on the insert statement
see the oracle documentation for more information about sequences, triggers and the returning clause
greetings
Freek D
I am new to Oracle and need to know how to create a table that uses an automatic incrementation on a primay key for it's default. I need the uniqueness automatically managed by the DBMS.. This activity is know as setting the Column (primary key with identity) in Ms-SQL..
Your help would be appreciated greatly....
Thanks....

Noob Question: Problem with Persistence in First Entity Bean

Hey folks,
I have started with EJB3 just recently. After reading several books on the topic I finally started programming myself. I wanted to develop a little application for getting a feeling of the technology. So what I did is to create a AppClient, which calls a Stateless Session Bean. This Stateless Bean then adds an Entity to the Database. For doing this I use Netbeans 6.5 and the integrated glassfish. The problem I am facing is, that the mapping somehow doesnt work, but I have no clue why it doesn't work. I just get an EJBException.
I would be very thankfull if you guys could help me out of this. And don't forget this is my first ejb project - i might need a very detailed answer ... I know - noobs can be a real ....
So here is the code of the application. I have a few methods to do some extra work there, you can ignore them, there are of no use at the moment. All that is really implemented is testConnection() and testAddCompany(). The testconnection() Methode works pretty fine, but when it comes to the testAddCompany I get into problems.
Edit:As I found out just now, there is the possibility of Netbeans to add a Facade pattern to an Entity bean. If I use this, everythings fine and it works out to be perfect, however I am still curious, why the approach without the given classes by netbeans it doesn't work.
public class Main {
    private EntryRemote entryPoint = null;
    public static void main(String[] args) throws NamingException {
        Main main = new Main();
        main.runApplication();
    private void runApplication()throws NamingException{
        this.getContext();
        this.testConnection();
        this.testAddCompany();
        this.testAddShipmentAddress(1);
        this.testAddBillingAddress(1);
        this.testAddEmployee(1);
        this.addBankAccount(1);
    private void getContext() throws NamingException{
        InitialContext ctx = new InitialContext();
        this.entryPoint = (EntryRemote) ctx.lookup("Entry#ejb.EntryRemote");
    private void testConnection()
        System.err.println("Can Bean Entry be reached: " + entryPoint.isAlive());
    private void testAddCompany(){
        Company company = new Company();
        company.setName("JavaFreaks");
        entryPoint.addCompany(company);
        System.err.println("JavaFreaks has been placed in the db");
    }Here is the Stateless Session Bean. I added the PersistenceContext, and its also mapped in the persistence.xml file, however here the trouble starts.
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
@Stateless(mappedName="Entry")
public class EntryBean implements EntryRemote {
    @PersistenceContext(unitName="PersistenceUnit") private EntityManager manager;
    public boolean isAlive() {
        return true;
    public boolean addCompany(Company company) {
        manager.persist(company);
        return true;
    public boolean addShipmentAddress(long companyId) {
        return false;
    public boolean addBillingAddress(long companyId) {
        return false;
    public boolean addEmployee(long companyId) {
        return false;
    public boolean addBankAccount(long companyId) {
        return false;
}That you guys and gals will have a complete overview of whats really going on, here is the Entity as well.
package ejb;
import java.io.Serializable;
import javax.persistence.*;
@Entity
@Table(name="COMPANY")
public class Company implements Serializable {
    private static final long serialVersionUID = 1L;
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    @Column(name="COMPANY_NAME")
    private String name;
    public Long getId() {
        return id;
    public void setId(Long id) {
        this.id = id;
   public String getName() {
        return name;
    public void setName(String name) {
        this.name = name;
        System.err.println("SUCCESS: CompanyName SET");
    @Override
    public int hashCode() {
        int hash = 0;
        hash += (id != null ? id.hashCode() : 0);
        return hash;
    @Override
    public boolean equals(Object object) {
        // TODO: Warning - this method won't work in the case the id fields are not set
        if (!(object instanceof Company)) {
            return false;
        Company other = (Company) object;
        if ((this.id == null && other.id != null) || (this.id != null && !this.id.equals(other.id))) {
            return false;
        return true;
    @Override
    public String toString() {
        return "ejb.Company[id=" + id + "]";
}And the persistence.xml file
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">
<persistence-unit name="PersistenceUnit" transaction-type="JTA">
    <provider>oracle.toplink.essentials.PersistenceProvider</provider>
    <jta-data-source>jdbc/sample</jta-data-source>
    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
      <property name="toplink.ddl-generation" value="create-tables"/>
    </properties>
</persistence-unit>
</persistence>And this is the error message
08.06.2009 10:30:46 com.sun.enterprise.appclient.MainWithModuleSupport <init>
WARNUNG: ACC003: Ausnahmefehler bei Anwendung.
javax.ejb.EJBException: nested exception is: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.RemoteException: Transaction aborted; nested exception is: javax.transaction.RollbackException: Transaktion für Zurücksetzung markiert.; nested exception is:
        javax.transaction.RollbackException: Transaktion für Zurücksetzung markiert.
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
        java.rmi.RemoteException: Transaction aborted; nested exception is: javax.transaction.RollbackException: Transaktion für Zurücksetzung markiert.; nested exception is:
        javax.transaction.RollbackException: Transaktion für Zurücksetzung markiert.
        at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.mapSystemException(Util.java:243)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:205)
        at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
        at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
        at ejb.__EntryRemote_Remote_DynamicStub.addCompany(ejb/__EntryRemote_Remote_DynamicStub.java)I spend half the night figuring out whats wrong, however I couldnt find any solution.
If you have any idea pls let me know
Best regards and happy coding
Taggert
Edited by: Taggert_77 on Jun 8, 2009 2:27 PM

Well I don't understand this. If Netbeans created a Stateless Session Bean as a facade then it works -and it is implemented as a CMP, not as a BMP as you suggested.
I defenitely will try you suggestion, just for curiosity and to learn the technology, however I dont have see why BMP will work and CMP won't.
I also don't see why a stateless bean can not be a CMP. As far as I read it should not matter. Also on the link you sent me, I can't see anything related to that.
Maybe you can help me answering these questions.
I hope the above lines don't sound harsh. I really appreciate your input.
Best regards
Taggert

Re: ReadOnly Entity Bean

Similar Messages

Maybe you are looking for