Hi Krish,
I just read the paper, to me, the Option A is very
interesting, as stated, Option A is only applied to insert
or read only data, but in our application, we want to use
this strategy to all entity beans, following is our requirement:
We want to use Option A to all entity bean, that means,
multi transations can access the same entity bean (the same pk),
the first committed transaction will successfully update the
transactional state, and all the following transactions that
change the transactional states can not commit transaction, the
container will throw exception during committing time if state were
really changed. Because this is our business logic has problem, we
need to change logic to get rid of this exception.
Let's take a look at the following scenario:
T1 and T2 both want to access PK=1, If 1 is in cache, container
just clone the instance and assign it to T1, later T2 comes, container
also clone the instance to T2; If 1 is not in cache, container will
load it from database, and put it in cache, and clone it to T1; later
T2 comes, container just clone the instance and assign it to T2. If T1
(maybe T2, because it may commit first) changed its state, the conatiner
will update the cache and also synchronize the database; if T2 also
changes its state, the container must throw out exception during
committing time.
The benefit for the above strategy is: we could concurrently access
the same entity bean, the bean was only loaded once and cached between
transactions.
Maybe there are some problems in the above scheme, if someone could
comment on it, I would appreciate it a lot.
Thanks
Regards
Jinsong
-----Original Message-----
From: Krishnan Subramanian [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 13, 2002 6:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Why entity beans? (added vendor caching)
Juan,
Many AppServers usually provide a way to tune the pool &
cache sizes of entity beans as one technique to limit the
number of entity bean instances.
However, this strategy usually gets thrown out of the
window when you start accessing a large number of entity
bean instances _within_ the scope of a single transaction
(say the results of a finder or an ejbSelect method).
This at least holds true of most AppServers I know of.
(bar us ;)
Given that your AppServer cannot be a memory hog or run
out of memory when you access a large number of entity
bean instances in a single transaction, there must be
some strategy in place to limit the number of entity
instances in memory. And a (potentially) long running
transaction should not really impact other concurrent
transactions running within the EJB Container.
The paper at:
http://community.borland.com/article/0,1410,29074,00.html
should explain our strategy. It also explains the various
Transaction Commit Options defined in the EJB spec as
implemented by a vendor. The transaction commit options
also translate to caching strategies implemented by a
vendor when using entity beans. Unfortunately, the commit
options defined in the spec [and their association with
caching strategies] still remains a source of confusion
(or ignorance) for many EJB developers.
-krish
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]] On Behalf Of Juan Pablo Lorandi
> Sent: 12 December 2002 11:54
> To: [EMAIL PROTECTED]
> Subject: Re: Why we need entity beans?????????
>
>
> Hola!!! Saludos desde Rosario.
>
> No, it doesn't mean that. Usually, Application Servers are
> smart enough
> to load EB to memory lazily. That means, if you're not using
> more than N
> records at a time, then only N beans are loaded.
>
> Juan Pablo Lorandi
> Chief Software Architect
> Code Foundry Ltd.
> [EMAIL PROTECTED]
>
> Barberstown, Straffan, Co. Kildare, Ireland.
> Tel: +353-1-6012050 Fax: +353-1-6012051
> Mobile: +353-86-2157900
> www.codefoundry.com
>
>
> > -----Original Message-----
> > From: A mailing list for Enterprise JavaBeans development
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Emilio
> Gustavo Orme�o
> > Sent: Wednesday, December 11, 2002 11:31 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Why we need entity beans?????????
> >
> >
> > Does it mind that, if I had a two millions records table,
> > I'll need a lot of memory to support each instance of the
> > entity bean ?
> >
> > Satyanarayana_Godavarti escribi�:
> >
> > >Hi Murali,
> > >
> > >Session bean meant for your business process. It can do a
> > simple thing
> > >like tax calculation or connecting to another bean etc.
> The session
> > >beans are verbs of your application. You cannot handle transaction
> > >management through session bean. At the best you can get the
> > data from
> > >the database but you cannot do update existing record or
> > adding a new
> > >record in the database.
> > >
> > >The entity beans are nouns of your application. These are your
> > >persistence objects. It represents your permanent data.
> Entity beans
> > >are capable of handling the transactions. Each table in your
> > database
> > >represents one entity bean and each instance of a bean
> represents a
> > >record in that table.
> > >
> > >You can use session beans for transaction but you have to go for
> > >Synchronized session beans.
> > >
> > >Regards,
> > >Murthy
> > >
> > >
> > >-----Original Message-----
> > >From: Murali Mohan [mailto:[EMAIL PROTECTED]]
> > >Sent: Wednesday, December 11, 2002 11:06 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: Why we need entity beans?????????
> > >
> > >
> > >Hi all,
> > >
> > >I have a basic doubt about entity beans???
> > >Why we need it????From sessionBeans also we can connect to
> DB and do
> > >all the operations.
> > >
> > >Why we need entity beans?????????What are extra uses???????
> > >
> > >Thanks,
> > >Mohan
> > >
> > >=============================================================
> > ==========
> > >====
> > >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".
> > >*************************************************************
> > *************
> > >This email (including any attachments) is intended for the
> > sole use of the
> > >intended recipient/s and may contain material that is
> > CONFIDENTIAL AND
> > >PRIVATE COMPANY INFORMATION. Any review or reliance by
> > others or copying or
> > >distribution or forwarding of any or all of the contents in
> > this message is
> > >STRICTLY PROHIBITED. If you are not the intended recipient,
> > please contact
> > >the sender by email and delete all copies; your cooperation
> > in this regard
> > >is appreciated.
> > >*************************************************************
> > *************
> > >
> > >=============================================================
> > ==========
> > >====
> > >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".
> > >
> > >
> > >
> >
> > --
> > Emilio Gustavo Orme�o Sarmiento
> > Licenciado en Informatica
> > [EMAIL PROTECTED]
> > Julio A. Roca Norte 637
> > San Juan - Capital
> > Tel. Par. 054 0264 4201514
> > Tel. Lab. 054 0265 4234129 int 139
> >
> > ==============================================================
> > =============
> > 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".
> >
> >
>
> =========================
> 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".
>
>
==========================================================================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".
===========================================================================
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".
