Hi!
Syed Fareed Ahmad wrote:
> Please forgive me if these questions has already been asked, actually our
> internet is too slow to access the whole EJB subscription over the net.
If you have not done so already, I recommend that you check the archives
at archives.java.sun.com. Many of the answers to your questions can be
found there.
> I have following questions
>
> For example, I have a BMP entity EJB and it also has a primary key. How does
> container handles the concurrency requirements. Like If one client calls
> findbyPrimaryKey("12") and it is given the Remote interface. Now an another
> calls findByPrimaryKey("12")? what the container will do ? It will block the
> second client or every client will be thier own copy? Do i need to do any
> dirty reading checking like (balance was 24 when EJB read the row or row is
> present in the database)? It will require extra programming ? should we do
> it?
If two clients access the same EJB by means of findByPrimaryKey they
will get their own copy of the EJBObject stub, but, both these will
point to the same EntityBean identity, 12 in your case. Concurrency is
handled by specifying the proper transaction delimitations. If an entity
with identity 12 is being used within a transaction it is typically
locked and may not be used by another transaction. I say "typically"
because this is the case with pessimistic concurrency, and if optimistic
concurrency is used then there will be copies. There are about a
thousand "if"'s involved here, so it is almost impossible to give an
exhaustive answer. Please specify your exact case in order to get an
answer that is relevant in your scenario.
It seems as though you're interested in "soft locks", which helps to
manually control who has access to what over time.
> We have used Connection (java.sql) objects in our ejbLoad and ejbStore code?
> But by default connection object is *autocommit* and every EJB example uses
> it in default mode? What internally happens? How container inetercept the
> connection object calls (if it was not obtained from the DataSource)? Should
> we do any commit stuff ourself or not?
You should only access connections from DataSources, in which case
Connections will be properly managed through the JTA and JDBC API's. If
you don't do this you're on your own. Strange behaviour abound.
> Whenever any of our BMP EJBs method is called? The ejbLoad and ejbStore is
> also called? How can I stop doing it? As I want Object scope Transactions
> management ?
Some servers lets you specify the characteristics of your deployment in
order to minimize the nr of ejbLoad/ejbStore calls. See your vendors
docs for details.
> Should we have the Primary Key one to one corresponding to the Database table
> PK or it can be customized to do some optimizations? If we can do that then
> how container will be able to do locking on the rows?
Each EntityBean has a PrimaryKey. If you have a 1-1 mapping between
EntityBean and table is up to you entirely. What is best is different
between different scenarios.
Sorry to be so diffuse in these answers, but they are inherently tricky,
and depend alot on the exact configuration of your deployment.
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.dreambean.com
Question reality
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
