Force read with entity beans

Hi,
is there a way to force the container to reload an Entity EJB (not read-only), something like read-timeout-seconds?
Thx,
A.

So you mean you're changing the data in the database and the entity bean isn't picking up these changes?
If you call ejbLoad() the container will instruct the instance to synchronize its state by loading its state from the underlying database (so reload the ejb basically)
Depending on what app server you're using - you can tell the container to call ejbLoad(), even if the data is already in cache, by default. This will probably be a setting in some .xml file.

Similar Messages

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

Caching data with Entity Bean

Hello,
I am performing some tests concerning the benefit of caching data with Entity Bean.
Here is the case :
I have an Entity Bean with a business method getName() to retrieve a name field in the EJB.
I understand that in order to cach data, I have to set the NOT_SUPPORTED transaction attr for this method. In this way, when this method is called, the ejbReload() is not called and the data is retreived from the EJB ready instance (and not from the database).
Is it true and is it the good way to use the cach mechanism ?
Now if we consider that this instance is the only one in the ready stage, and it is never pooled (it seems so !), what about a modification of the database from a tier (or from an other EB instance)? The Entity Bean is not able to see this modification seence it does not call the ejbLoad method.
Is there a way to force an Entity Bean to be periodically polled in order to recover data from the data store when activated ?
Thanks in advance,
Thierry

No, This is wrong way of doing what you want. Most of the application servers provide various configuration settings for this. Eg. caching mechanism, interval on when to call ejbLoad and ejbStore, read only beans. You have to check the documentation for this.
--Ashwani

Read Only entity beans and Finders

Hi,
We are using Read Only entity beans with WLS 7.0 SP1 for some entities that represent Reference Data that will never change. What I would like to know is whether WLS needs to hit the database when a finder on these beans is run or does WLS cache the results of the Finder also?
Thanks.
Santosh

Hi,
we use read only entity beans. It is beneficial if have findByPrimaryKey finders. but we also have finders on non primary key coloumn also. is there a way to cache such local references returned by such non primary key finders also.

Load balancing not happending but fail over is for Read only Entity beans

          The following are the configuration.
          Two NT servers with WL5.1 sp9 having only EJBs(Read only entity beans)
          One Client with WL5.1 sp9 having servlet/java application as
          EJB client.
          I am trying to make a call like findbyprimarykey in one of the
          entity bean. I could see the request is being directed only to the one of the
          server always. When I bring that server, fail over is happening to the other server.
          Here are the settings I have in the ejb-jar.xml :
                    <entity>
                         <ejb-name>device.StartHome</ejb-name>
                         <home>com.wl.api.device.StartHome</home>
                         <remote>com.wl.api.device.StartRemote</remote>
                         <ejb-class>com.wl.server.device.StartImpl</ejb-class>
                         <persistence-type>Bean</persistence-type>
                         <prim-key-class>java.lang.Long</prim-key-class>
                         <reentrant>False</reentrant>
                         <resource-ref>
                              <res-ref-name>jdbc/wlPool</res-ref-name>
                              <res-type>javax.sql.DataSource</res-type>
                              <res-auth>Container</res-auth>
                         </resource-ref>
                    </entity>
          Here are the settings I have in the weblogic-ejb-jar.xml.
          <weblogic-enterprise-bean>
                    <ejb-name>device.StartHome</ejb-name>
                    <caching-descriptor>
                         <max-beans-in-cache>50</max-beans-in-cache>
                         <cache-strategy>Read-Only</cache-strategy>
                         <read-timeout-seconds>900</read-timeout-seconds>
                    </caching-descriptor>
                    <reference-descriptor>
                         <resource-description>
                              <res-ref-name>jdbc/wlPool</res-ref-name>
                              <jndi-name>weblogic.jdbc.pool.wlPool</jndi-name>
                         </resource-description>
                    </reference-descriptor>
                    <enable-call-by-reference>False</enable-call-by-reference>
                    <jndi-name>device.StartHome</jndi-name>
               </weblogic-enterprise-bean>
          Am I doin any mistake in this?
          Any one's help is appreciated.
          Thanks
          Suresh


we are using 5.1
          "Gene Chuang" <[email protected]> wrote in message
          news:[email protected]...
          > Colocation optimization occurs if your client resides in the same
          container (and also in the same
          > EAR for 6.0) as your ejbs.
          >
          > Gene
          >
          > "Suresh" <[email protected]> wrote in message
          news:[email protected]...
          > > Ok....the ejb-call-by-reference set to true is making the call to one
          server
          > > only. i am not sure why it is. I removed the property name and it
          works.
          > > Also I have one question, in our prduct environment, when i cache the
          ejb
          > > home it is not doing the load balancing. can any one help me for that.
          > > thanks
          > >
          > > Mike,
          > > From the sample pgm I sent, even from single client calls get load
          > > balanced.
          > >
          > > Suresh
          > >
          > >
          > > "Gene Chuang" <[email protected]> wrote in message
          > > news:[email protected]...
          > > > In WL, LoadBalancing will ONLY WORK if you reuse your EJBHome! Take
          your
          > > StartEndPointHome lookup
          > > > out of your for loop and see if this fixes your problem.
          > > >
          > > > I've seen this discussion in ejb-interest, and some other vendor
          (Borland,
          > > I believe it is), brings
          > > > up an interesting point: Clustering and LoadBalance is not in the
          J2EE
          > > specs, hence implementation
          > > > is totally up to the vendor. Weblogic loadbalances from the remote
          > > interfaces (EJBObject, EJBHome,
          > > > etc..), while Borland loadbalances from JNDI Context lookup.
          > > >
          > > > Let me suggest a third implmentation: loadbalance from BOTH Context
          > > lookup as well as stub method
          > > > invocation! Or create a smart replica-aware list manager which
          persists
          > > on the client thread
          > > > (ThreadLocal) and is aware of lookup/evocation history. Hence if I do
          the
          > > following in a client
          > > > hitting a 3 node cluster, I'll still get perfect round-robining
          regardless
          > > of what I do on the
          > > > client side:
          > > >
          > > > InitialContext ctxt = new InitialContext();
          > > > EJBHome myHome = ctxt.lookup(MY_BEAN);
          > > > myHome.findByPrimaryKey(pk); <== hits Node #1
          > > > myHome = ctxt.lookup(MY_BEAN);
          > > > myHome.findByPrimaryKey(pk); <== hits Node #2
          > > > myHome.findByPrimaryKey(pk); <== hits Node #3
          > > > myHome = ctxt.lookup(MY_BEAN);
          > > > myHome.findByPrimaryKey(pk); <== hits Node #1
          > > > ...
          > > >
          > > >
          > > > Gene
          > > >
          > > > "Suresh" <[email protected]> wrote in message
          > > news:[email protected]...
          > > > > Mike ,
          > > > >
          > > > > Do you have any reasons for the total number of machines to be 10.
          > > > >
          > > > > I tried with 7 machines.
          > > > >
          > > > >
          > > > > Here is my sample client java application running individual in the
          > > seven
          > > > > machines.
          > > > >
          > > > > StartEndPointHome =
          > > > > (StartEndPointHome)ctx.lookup("dev.StartEndPointHome");
          > > > > for(;;)
          > > > > {
          > > > > // logMsg(" --in loop "+currentTime);
          > > > > if (currentTime > nextRefereshTime)
          > > > > {
          > > > > logMsg("****- going to call");
          > > > > currentTime=getSystemTime();
          > > > > nextRefereshTime=currentTime+timeInterval;
          > > > > StartEndPointHome =
          > > > > (StartEndPointHome)ctx.lookup("dev.StartEndPointHome");
          > > > > long rndno=(long)(Math.random()*10)+range;
          > > > > logMsg(" going to call remotestub"+rndno);
          > > > > retVal =
          > > > >
          > >
          ((StartEndPointHome)getStartHome()).findByNumber("pe"+rndno+"_mportal_dsk36.
          > > > > mportal.com");
          > > > >
          > > > > logMsg("**++- called stub");
          > > > > }
          > > > >
          > > > >
          > > > >
          > > > > The range value is different for each of the machines in the
          cluster.
          > > > >
          > > > > If the first request starts at srv1, all request starts hitting the
          same
          > > > > server.
          > > > > If the first request starts at srv2, all request starts hitting the
          same
          > > > > server.
          > > > >
          > > > > I have the following for the url , user and pwd values for the
          context
          > > .
          > > > >
          > > > > public static String url="t3://10.11.12.14,10.11.12.117:8000";
          > > > > public static String user="guest";
          > > > > public static String password="guest";
          > > > >
          > > > >
          > > > >
          > > > > It would be great if you could help me.
          > > > >
          > > > > Thanks
          > > > > suresh
          > > > >
          > > > >
          > > > > "Mike Reiche" <[email protected]> wrote in message
          > > > > news:[email protected]...
          > > > > >
          > > > > > If you have only one client don't be surprised if you only hit one
          > > server.
          > > > > Try
          > > > > > running ten different clients and see if the hit the same server.
          > > > > >
          > > > > > Mike
          > > > > >
          > > > > >
          > > > > > "suresh" <[email protected]> wrote:
          > > > > > >
          > > > > > >The following are the configuration.
          > > > > > >
          > > > > > > Two NT servers with WL5.1 sp9 having only EJBs(Read only entity
          > > beans)
          > > > > > >
          > > > > > > One Client with WL5.1 sp9 having servlet/java application as
          > > > > > > EJB client.
          > > > > > >
          > > > > > >
          > > > > > >I am trying to make a call like findbyprimarykey in one of the
          > > > > > >entity bean. I could see the request is being directed only to
          the
          > > one
          > > > > > >of the
          > > > > > >server always. When I bring that server, fail over is happening
          to
          > > the
          > > > > > >other server.
          > > > > > >
          > > > > > >
          > > > > > >Here are the settings I have in the ejb-jar.xml :
          > > > > > > <entity>
          > > > > > > <ejb-name>device.StartHome</ejb-name>
          > > > > > > <home>com.wl.api.device.StartHome</home>
          > > > > > > <remote>com.wl.api.device.StartRemote</remote>
          > > > > > > <ejb-class>com.wl.server.device.StartImpl</ejb-class>
          > > > > > > <persistence-type>Bean</persistence-type>
          > > > > > > <prim-key-class>java.lang.Long</prim-key-class>
          > > > > > > <reentrant>False</reentrant>
          > > > > > > <resource-ref>
          > > > > > > <res-ref-name>jdbc/wlPool</res-ref-name>
          > > > > > > <res-type>javax.sql.DataSource</res-type>
          > > > > > > <res-auth>Container</res-auth>
          > > > > > > </resource-ref>
          > > > > > > </entity>
          > > > > > >
          > > > > > >
          > > > > > >Here are the settings I have in the weblogic-ejb-jar.xml.
          > > > > > >
          > > > > > ><weblogic-enterprise-bean>
          > > > > > > <ejb-name>device.StartHome</ejb-name>
          > > > > > >
          > > > > > > <caching-descriptor>
          > > > > > > <max-beans-in-cache>50</max-beans-in-cache>
          > > > > > > <cache-strategy>Read-Only</cache-strategy>
          > > > > > > <read-timeout-seconds>900</read-timeout-seconds>
          > > > > > > </caching-descriptor>
          > > > > > >
          > > > > > > <reference-descriptor>
          > > > > > > <resource-description>
          > > > > > > <res-ref-name>jdbc/wlPool</res-ref-name>
          > > > > > > <jndi-name>weblogic.jdbc.pool.wlPool</jndi-name>
          > > > > > > </resource-description>
          > > > > > > </reference-descriptor>
          > > > > > > <enable-call-by-reference>False</enable-call-by-reference>
          > > > > > > <jndi-name>device.StartHome</jndi-name>
          > > > > > > </weblogic-enterprise-bean>
          > > > > > >
          > > > > > >
          > > > > > >Am I doin any mistake in this?
          > > > > > >
          > > > > > >Any one's help is appreciated.
          > > > > > >Thanks
          > > > > > >Suresh
          > > > > >
          > > > >
          > > > >
          > > >
          > > >
          > >
          > >
          >
          >

Primary Key for Read Only Entity Beans In EJB 3.0

Hi,
I have checked the spec for ejb 3.0 which mentions that, there is no common standard for the vendor to implement the Read only Entity Beans.
My question over here is how it is implemented in OC4J??
Do we need to specify a primary key attribute in the read-only entity bean?
w.r.t BC4J(ADF) i remember, we used to create a read-only View Object with out specifying a primary key.
Just want to check is that the way it works in EJB 3.0 (Implemented by OC4J).
Thanks for your help in advance.
Shiva

Hi,
Try using the JBoss embedded container:
http://docs.codehaus.org/display/MAVENUSER/How+to+use+the+JBoss+Embedded+EJB3+Container+for+Unit+testing
/klejs

Read Only Entity Bean will not cache

I'm using the Sun Java Application Server version 8.2. I've created a read only entity bean with a 900 second refresh. This bean has a findAll() method that I've created. The table it is reading from has only 22 rows of data that doesn't change (well, maybe 2 or 3 times a year).
As stated I've set the read-only property to true and the refresh to 900 seconds. I've also set the caching settings, which I guess i don't really need to mess with from the defaults.
I do not seem to be achieving any caching at all. My check for this is very simple. I simply load a drop down in the client application with these 22 values. After the intial load I add another row in the database. The newley added row always shows up in the drop down in real time. If i'm caching correctly I shouldn't see this value until the refresh time of 900 seconds. Is there something I am missing? I'm using NetBeans 5.0 to set the values of the entity beans and such.
Thanks for the help!
ryan

Hi Ryan,
The 8.2 read-only bean implementation still executes non-findByPrimaryKey queries within the database.
If your application calls findByPrimaryKey or accesses a business method on one of the
read-only beans returned from a query, that will not result in a database access (unless a refresh
period boundary is crossed).
We have added the additional optimization of caching specific result sets of non-findByPrimaryKey
read-only bean finders in the latest development version of Glassfish (V2).
https://glassfish.dev.java.net/public/downloadsindex.html#Official_supported_builds
It will also be available in our Application Server release 9.1. There are no plans to backport this
optimization to the 8.2 codebase.
--ken

Clustering read-write entity beans

          reading the WLS 6.1 documentation, it's unclear to me whether read-write entity
          bean
          method calls load-balancing and failover are supported. here's an excerpt from
          "Understanding Object Clustering":
          "When a home finds or creates a read-write entity bean, it obtains an instance
          on
          the local server and returns a stub pinned to that server. Load balancing and
          failover occur only at the home level."
          but here's what i find under "The WebLogic Server EJB Container":
          "read-write entity EJBs supports automatic failover on a safe exception,
          if home-is-clusterable is set to true. For example, failover is automatically
          supported if there is a failure after a method completes, or if the method
          fails to connect to a server."
          anyone know which is true?
          yan


In WLS 6.1, there is fail-over for entity beans in a cluster. The stub contains a
          special load-balancing algorithm that returns to your original server until it
          fails. Then it will fail-over to a new server. If a server fails during a
          method-call, automatic fail-over only happens on a safe exception. Basically, when
          WLS determines that you have not actually connected to the failed server and have
          not done any work in the current transaction.
          -- Rob
          Yan wrote:
          > reading the WLS 6.1 documentation, it's unclear to me whether read-write entity
          > bean
          > method calls load-balancing and failover are supported. here's an excerpt from
          > "Understanding Object Clustering":
          >
          > "When a home finds or creates a read-write entity bean, it obtains an instance
          > on
          > the local server and returns a stub pinned to that server. Load balancing and
          > failover occur only at the home level."
          >
          > but here's what i find under "The WebLogic Server EJB Container":
          >
          > "read-write entity EJBs supports automatic failover on a safe exception,
          > if home-is-clusterable is set to true. For example, failover is automatically
          > supported if there is a failure after a method completes, or if the method
          >
          > fails to connect to a server."
          >
          > anyone know which is true?
          >
          > yan
          AVAILABLE NOW!: Building J2EE Applications & BEA WebLogic Server
          by Michael Girdley, Rob Woollen, and Sandra Emerson
          http://learnWebLogic.com
          [att1.html]

Deployment problem sdk 1.4 with entity bean

hallo!
i have a big problem with the j2ee sdk 1.4. when i want to add an entity bean to my ear-file, everything goes good, but when i put the sql-ql for the finder-method and save the file i got an error like this
xxxxxxx.ear is corrupt or cannot be read
when i dont save and will show the descriptor it generates an empty descriptor for this entity bean.
the problem is, that the deployment tool cannot generate the deployment desciptor for entity beans. with session bean there was no problems.
hope somebody can help me.
thanks

There's bug in non-U.S. locales. The workaround is described in this thread:
http://forum.java.sun.com/thread.jsp?forum=136&thread=472692&tstart=15&trange=15
-Ian Evans
Sun Microsystems
J2EE Tutorial team

Re: Read Only Entity Bean

I am trying to convert an entity bean into a read only bean .
I am not sure how it works ? I read the documentation and it said that I had to
set
the following parameters
cache-strategy>Read-Write</cache-strategy>
read-timeout-seconds>100</read-timeout-seconds>
If I set the time out time to 100 seconds will the container call the ejbLoad
method
to reload the bean after every 100 seconds or only when the a request is made
on the
bean
Thanks a lot in advance for your answers.

Kevin,
"Kevin" <[email protected]> wrote in message
news:3ec25923$[email protected]..
I am trying to convert an entity bean into a read only bean .
I am not sure how it works ? I read the documentation and it said that Ihad to
set
the following parameters
cache-strategy>Read-Write</cache-strategy>
read-timeout-seconds>100</read-timeout-seconds>
If I set the time out time to 100 seconds will the container call theejbLoad
method
to reload the bean after every 100 seconds or only when the a request ismade
on the
bean
Thanks a lot in advance for your answers.read-timeout-seconds make sense only for Read-Only
cache strategy and defines cache element expiration time.
For Read-Write strategy data will be loaded from the database
in with every new transaction (if db-is-shared set to true).
Hope this helps.
Regards,
Slava Imeshev

Strange behavior with entity beans and servlets in a cluster

We have 2 WebLogic 4.5.1 servers in a cluster with none of the Service
          Packs installed. When a client uses the deployed entity beans or
          servlets they work every other time. The times they do not work nothing
          happens. No exceptions, no responses to the client ( i.e. HTTP 404s ),
          nothing. I suspect something in the cluster setup since we do not have
          these same problems on non-clustered entity beans or servlets. We have
          made sure all the entity beans have the Shared Database flag set on and
          added the delayUpdatesUntilEndOfTx false to the enviroment of the DD.
          That didn't fix the problem. Any ideas?
          Thanks in advance,
          Dallas Dempsey
          DEM - Houston, TX


Do you have log files?
          - Prasad
          Chris Dempsey wrote:
          > We have 2 WebLogic 4.5.1 servers in a cluster with none of the Service
          > Packs installed. When a client uses the deployed entity beans or
          > servlets they work every other time. The times they do not work nothing
          > happens. No exceptions, no responses to the client ( i.e. HTTP 404s ),
          > nothing. I suspect something in the cluster setup since we do not have
          > these same problems on non-clustered entity beans or servlets. We have
          > made sure all the entity beans have the Shared Database flag set on and
          > added the delayUpdatesUntilEndOfTx false to the enviroment of the DD.
          > That didn't fix the problem. Any ideas?
          >
          > Thanks in advance,
          > Dallas Dempsey
          > DEM - Houston, TX

Problem with transaction with Entity Beans in R2

I had a transaction (initiated by a session bean (requires new)) that takes two entity beans (two bank accounts) and trasfer funds from one to another. It looks like the container is waiting for the transaction, i don't know, here comes the exception I get (this code used to work with a lot of simultaneous clients with R1) :
com.evermind.server.ejb.TimeoutExpiredException: timeout expired waiting for an instance
at com.evermind.server.ejb.DBEntityWrapperPool.getWrapperInstance(DBEntityWrapperPool.java:189)
at com.evermind.server.ejb.DBEntityEJBHome.getWrapperInstance(DBEntityEJBHome.java:135)
error: Remote: Database error, IO failure: com.evermind.server.rmi.OrionRemoteException: Error enlisting connection resource: javax.transaction.RollbackException: The transaction has been marked for rollback (timed out); nested exception is:
javax.transaction.RollbackException: The transaction has been marked for rollback (timed out); nested exception is:
com.evermind.server.rmi.OrionRemoteException: Error enlisting connection resource: javax.transaction.RollbackException: The transaction has been marked for rollback (timed out); nested exception is:
javax.transaction.RollbackException: The transaction has been marked for rollback (timed out)
above goes the ejb-jar.xml
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.2//EN" "http://java.sun.com/j2ee/dtds/ejb-jar_1_2.dtd">
<ejb-jar>
<description>
</description>
<enterprise-beans>
<session>
<description>
</description>
<ejb-name>ContaFacadeEJB</ejb-name>
<home>contacorrente.ContaFacadeHome</home>
<remote>contacorrente.ContaFacade</remote>
<ejb-class>contacorrente.ContaFacadeBean</ejb-class>
<ejb-ref>
<ejb-ref-name>ContaCorrenteEJB</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>contacorrente.ContaCorrenteHome</home>
<remote>contacorrente.ContaCorrente</remote>
</ejb-ref>
</session>
<entity>
<description>
</description>
<ejb-name>ContaCorrenteEJB</ejb-name>
<home>contacorrente.ContaCorrenteHome</home>
<remote>contacorrente.ContaCorrente</remote>
<ejb-class>contacorrente.ContaCorrenteBean</ejb-class>
<primkey-class>java.lang.String</primkey-class>
<reentrant>True</reentrant>
<persistence-type>Container</persistence-type>
<cmp-field><field-name>id_conta</field-name></cmp-field>
<cmp-field><field-name>saldo</field-name></cmp-field>
<cmp-field><field-name>senha</field-name></cmp-field>
<primkey-field>id_conta</primkey-field>
</entity>
</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>ContaFacadeEJB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
<container-transaction>
<method>
<ejb-name>ContaCorrenteEJB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Mandatory</trans-attribute>
</container-transaction>
</assembly-descriptor>
</ejb-jar>
and the code of the beans (just the method used)
Entity (account)
public void debita(double valor) throws ContaCorrenteException
double saldoOld=saldo;
saldo=saldo-valor;
if (saldo<0)
throw new ContaCorrenteException("Saldo insuficiente:"+saldoOld);
Session :
public void transfere(String idConta1, String idConta2, double valor, String senha) throws ContaCorrenteException
try
Context cx=new InitialContext();
Object homeObject=cx.lookup("java:comp/env/ContaCorrenteEJB");
ContaCorrenteHome home=(ContaCorrenteHome) PortableRemoteObject.narrow(homeObject,ContaCorrenteHome.class);
ContaCorrente c1=null;
ContaCorrente c2=null;
try
c1=home.findByPrimaryKey(idConta1);
c2=home.findByPrimaryKey(idConta2);
if (!c1.getSenha().equals(senha)) { throw new ContaCorrenteException("Senha incorreta");}
catch(FinderException e)
System.out.println("erro ao localizar conta :"+e.getMessage());
context.setRollbackOnly();
throw new ContaCorrenteException("Conta inexistente");
catch(java.rmi.RemoteException e)
System.out.println("erro Remote: "+e.getMessage());
context.setRollbackOnly();
throw new ContaCorrenteException("Erro ao conectar objeto remoto");
try
c1.debita(valor);
c2.credita(valor);
catch(ContaCorrenteException e)
context.setRollbackOnly();
throw new ContaCorrenteException(e.getMessage());
catch(java.rmi.RemoteException e)
throw new ContaCorrenteException("Erro de conexco");
catch (NamingException e)
System.out.println("erro de localizagco:"+e.getMessage());
throw new ContaCorrenteException("Erro de acesso remoto na localizacao da conta");
please, someone help me...
Thanks in advance

I forgot : when i try to shut the server down i get the message :
Shutting down...
Error serializing bean: Deadlock detected, timing out call after 15 seconds wait for transaction [Transaction d9:fa:4f:b6:ff:ff:ff:ff:4a:0:0:0:0:0:0:0:0:4b:0:ec:6d:ce:c0:16]
Error serializing bean: Deadlock detected, timing out call after 15 seconds wait for transaction [Transaction d9:fa:4f:b6:ff:ff:ff:ff:4c:0:0:0:0:0:0:0:0:4d:0:ec:6d:d2:d9:d2]
Error serializing bean: Deadlock detected, timing out call after 15 seconds wait for transaction [Transaction d9:fa:4f:b6:ff:ff:ff:ff:4e:0:0:0:0:0:0:0:0:4f:0:ec:6d:d4:21:a3]
and it doesn't shutdown.

Creating Webservice with entity bean

I am trying to create a webservice(using entity bean). Using ANT i am building
up the .ear file. My source files are placed in a directory (c:\test) . I have
set the path and invoked ANT .In the build.xml file , when it is trying to compile
the ejb classes , it gives me the following error:
ERROR: Error from ejbc: Could not locate bean with ejb-name 'EBankEJBean'
in weblogic-ejb-jar.xml
Can anybody pls help me out !
thanx
arthi

WLS 7.0 only supports stateless session bean or a plain java
class as web service.
From your post it seems you have trouble doing ejbc.
You will get better answer if you post this in the ejb
newsgroup.
regards,
-manoj
"arthi" <[email protected]> wrote in message
news:[email protected]..
I am trying to create a webservice(using entity bean). Using ANT i am building
up the .ear file. My source files are placed in a directory (c:\test) . I have
set the path and invoked ANT .In the build.xml file , when it is trying to
compile
the ejb classes , it gives me the following error:
ERROR: Error from ejbc: Could not locate bean with ejb-name 'EBankEJBean'
in weblogic-ejb-jar.xml
Can anybody pls help me out !
thanx
arthi
[att1.html]

Jprobe Memory Debugger with Entity Bean

hi,
I m testing an EJB application(Bean Managed) using Jprobe Memory debugger.
While testing it gives me that objects referred by entity bean are loitering . for eg if somewhere in my code i created an integer using new Integer and if I m letting it passed to ejbCreate .then that object is pointed as loitering while debugging. further it happens with srtring and data access Objects and otheres as well.
so is there a memory Leak or The debugger is handling the entity bean in such a way.
version of jprobe used is 5.2.3 on windows
Please provide me help regarding the same

Actually, what one or the developers in my group found out is two things:
1) The clone is a shallow copy.They copy the references but not objects themselves. This has been causing problems for us.
2) It seems that you don't work on a copy and you work on the original and they keep a copy. Now, this is fine IF you don't have multiple threads working on the same Entity bean and we moved our application from Weblogic where it throws an exception if that Entity bean is in use to OC4J which is suppose to copy the bean and doesn't so you have multiple threads possibly modifying the same object.

Report with entity beans - BIG performance problem

I have several EJBs (CMP entity beans).
I need to build a report using linked EJBs and show this report
to a user (so, updates are not needed - report is only for web page demonstration).
the problem is: such report is generated too slow.
I have ~100 records in table 'TestResult' and ~500 records in table 'TestObject'.
these tables are linked like this:
one testobject <--> many testresults
for each testresult I need to show a line with some info which should be retrieved
from bound EJBs (e.g. testresult-testobject-assigneduser-prioritylevel)
how to optimize such report generation?
I have heard something about session beans with Value Objects.
do I need to use such session beans here?
what is a general solution for generating reports using linked EJBs?
I tried to solve the problem by using DB View, but it didn't help.
I have used 'TestResultView' - info is retrieved fast enough from this view
(several msecs), but displaying this info is still very costly.
please, help!
Oracle 8.1.7,
WebLogic 6.1

Hi,
because I have checked the time required to
1) retrieve EJBS (several msec)Let me share some of my views with you.Once you retrieve the EJBS ie ie the collection of remote interface from the finder method the container is firing single "select " query and gets all the primary keys back.
2) cycle through it - get fields and display them
(~4000 msec)Now the cycle of getting the value you are getting the bean from the PooledState to ready state which will get the fields by firing the "select" query (ejbload()). Now in the instance you are invoking the multiple methods and at the end it will remain there in ready till you call the remove which u are not doing so the time out will bring it back to the pooledstate.
And if you are calling the bean very frequently then all the instances will go to the ready state and the activation & passivation will start developing ......
So at the end when the bean moves back to the pooled state after timeout the ejbStore() fires the "update " query!!!!
Let us consider the activation/passivation not appearing for simple understanding !!!!!!!!
So for each iteration you are firing 2 queries to the database.So if you have 500 records then the queries generatted will be 1(select from finder)+2(1 by select(ejbload)+1 by update(ejbStore))*500. So the flow is calling 1001 queries ...Thus quering about 1000 queries will definetly take some time...
So what is the solution????
Any way you dont require to fire the update query as you are just viewing the data...So u can stop calling the ejbStore().
Hence you queries will drop to half.Now how we can do this is by using the BMP.....
The other solution is using the Sessionbean and store the data all 500 records in the Object which can be called across the n/w. This object should implements the Serializable interface and this tech is the Transfer Object feature.....
Hope you find this useful..
regards
Vicky

Force read with entity beans

Similar Messages

Maybe you are looking for