Jinsong, We do provide some of the solutions you are looking for. If I understand you correctly, you want to ensure that one transaction does not overwrite the changes made by another (concurrent) transaction. This is easily achieved in our AppServer by selecting an optimistic concurrency mode for that bean. See:
http://swjscmail1.java.sun.com/cgi-bin/wa?A2=ind0112&L=ejb-interest&P=R1 7393 <vendor> Option A in our EJB Container implementation allows you to also modify data - as long as our EJB Container is not clustered and/or the database is not updated by an application other than the EJB Container (say a legacy app). If you do cluster the Container or have some other app update the database, then Option A cannot be used with our product unless the data is insert-only. </vendor> Some vendors attempt to solve the problem by providing a timeout period for cached entity bean instances. And other solutions involve having cluster instances send multicast messages or the likes. Each solution has its own drawbacks (and few benefits). But the overhead of ensuring that cached data remains [transactionally] consistent across a cluster _might_ actually negate the benefits of using such a cache in the first place. But of course certain third party products exist which do provide such functionality - and coupled with Option A in our Container; these might prove to be a high performant solution. You might want to check up the www.theserverside.com for solutions and patterns that describe this problem in greater detail. -krish > -----Original Message----- > From: A mailing list for Enterprise JavaBeans development > [mailto:[EMAIL PROTECTED]] On Behalf Of Hu, Jinsong > Sent: 13 December 2002 16:47 > To: [EMAIL PROTECTED] > Subject: Re: Why entity beans? (added vendor caching) > > > 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". > > ==========================================================================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".
