Transactions, Persistence Contexts and Entity Managers... Oh My!

Hi
I am just getting into J2EE and EJB3. I have no prior experience with EJB2, we avoided it with our own POJO data access framework. With the advent of EJB3 we would like to use it in a new application.
I am reading the book "Pro EJB 3" by Ketih and Schincariol and am having trouble wrapping my head around then Entity Manager chapter. I don't think it's any fault of the authors, but somehow it's just not coming together in my head. Perhaps it's because I have no real prior EJB experience.
Can anyone point me to a resource that gives an overview of the relationships between Transactions, Persistence Contexts and Entity Managers? Or perhaps I just have to keep mulling it over until it all comes together...?
Thanks in advance!

Hi Shelli,
I haven't read that book but I don't know of a good writeup of the tx topic specifically outside
of the spec itself. There are certainly a lot of combinations, between container-managed
vs. bean-managed EntityManagers, and JTA vs. resource-local. However, the
common usage case within Java EE -- container-managed and JTA -- is very simple.
In this case, the container automatically associates the persistence context with the
active global transaction. If you make a call to another Java EE component within the
same transaction and that component accesses a container-managed EntityManager
for the same persistence unit, the persistence context is automatically propagated so
that both components "see" the same persistence context.
--ken

Similar Messages

Extended Persistence Context And user transaction

Hello
I use Extended persistence context with stateful session bean in my app, but when i persist object it does not store in database,i dont know whats wrong:
@Stateful
@TransactionManagement(TransactionManagementType.BEAN)
public class ProfessionAction implements ProfessionLocal {
     @PersistenceContext(type = PersistenceContextType.EXTENDED)
     private EntityManager em;
     @Transient
     private Logger log;
     @Resource
     private UserTransaction ut;
     public Profession add( Profession p) {
          try {
               log.info("Adding Profession...");
               ut.begin();
               em.persist(p);
               ut.commit();
               log.info("Profession Added...");
          } catch (Exception ex) {
               log.error(ex.getMessage(), ex);
          return p;
     }

What if you change the code to this:
@Stateful
@TransactionManagement(TransactionManagementType.BEAN)
public class ProfessionAction implements ProfessionLocal {
@PersistenceContext(type = PersistenceContextType.EXTENDED)
private EntityManager em;
@Transient
private Logger log;
public Profession add( Profession p) {
try {
log.info("Adding Profession...");
em.getTransaction().begin();
em.persist(p);
em.getTransaction().commit();
log.info("Profession Added...");
} catch (Exception ex) {
log.error(ex.getMessage(), ex);
return p;
}?

EJB 3.0 Locking (entity not in the persistence context)

hi all,
i have some problems about locking,
i have 1 remote and one local interface
1. Remote Interface
public @Stateful
@Remote(RemoteInterface.class)
class RemoteInterfaceBean implements RemoteInterface
       @PersistenceContext(unitName = "CustomerCareOracle")
     private EntityManager oracleManager;
        public MySomeEntityObject object;
       @EJB
        MyLocalInterface inter;
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void fillMyObject(someparameters .... )
      // filling MySomeEntityObject object
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public void commitMyObject()
      inter.AnotherOperatOnObject(object);
      oracleManager.persist(object);
2. My Local Interface
public @Stateless
@Local(MyLocalInterface.class)
class MyLocalInterfaceBean implements MyLocalInterface
       @PersistenceContext(unitName = "CustomerCareOracle")
     private EntityManager oracleManager;
        @TransactionAttribute(TransactionAttributeType.REQUIRED)
         public void AnotherOperatOnObject(MySomeEntityObject object)
               oracleManager.lock(object,LockModeType.READ);
// <= Here I Got An Error
               // do some operation and is succsess, It's very good ;)
}     when i tryed to lock object i got an error, i can't resolve this problem :(
can anybody help me ?
error trace
17:43:21,343 ERROR [errorCat] java.lang.IllegalArgumentException: entity not in the persistence cont
ext
        at org.hibernate.ejb.AbstractEntityManagerImpl.lock(AbstractEntityManagerImpl.java:336)
        at org.jboss.ejb3.entity.TransactionScopedEntityManager.lock(TransactionScopedEntityManager.
java:101)
        at com.magti.businesslayer.ejb3Fasade.oracle.ccare.TransactionFasadeBean.lockAccounts(Transa
ctionFasadeBean.java:203)
        at com.magti.businesslayer.ejb3Fasade.oracle.ccare.TransactionFasadeBean.doAfterCheck(Transa
ctionFasadeBean.java:76)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
        at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
        at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor
.java:63)
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
        at org.jboss.ejb3.entity.ExtendedPersistenceContextPropagationInterceptor.invoke(ExtendedPer
sistenceContextPropagationInterceptor.java:57)     Regards,
Paata.

It looks like you're trying to call lock before the entity has been created within the persistence
context. Persist the entity within the persistence context before calling lock.

Multiple Persistence Units AND one transaction

Hello,
I'm using JPA implementation for my EJB Project.
I have 2 persistence units and I'm using them in the same method.
I want to persist 2 object belonging each one to a different persistence unit
The 2 persistence units are related to different databases.
Everything is going fine and no exception is raised BUT only one object is persisted and the other one is not.
Have anyone had a similar problem before.
Any help will be appreciated.
Thanks in advance.
Edited by: ImaneA on Jan 18, 2011 9:29 AM

@Yordan :
First of all, thanks a lot for you answer.
At the end, I didn't use two EJB Projects :
1 - I used only one datasource( associated to one database ) in the persistence.xml
2 - I created a DBLink in SQL Server
3 - I created a synonym in the first database to get data from the second database.
And it works
But thanks for the answer, I may use you solution in my next project
@Rolf :
No, In NWA I've declared my datasources as normal datasources.
But Plz if you have docs that talks about XDataSources plz share them and thanks in advance.
Edited by: ImaneA on Jan 25, 2011 9:21 AM

JPA and Entity manager.

Hi all,
I have a "simple" question:
Should I create a class to manage entity manager and entity manager factory on JPA2?
Why do I ask that? Because I read on J2EE tutorial:
With a container-managed entity manager, an EntityManager instance’s persistence context is automatically propagated by the container to all application components that use the EntityManager instance within a single Java Transaction Architecture (JTA) transaction.
To obtain an EntityManager instance, inject the entity manager into the application component:
@PersistenceContext
EntityManager em;
I'm using JSF2, JPA2, JTA and Glassfish3.1 on the NetBeans 7.0.1.
The wizard that creates the JSF's pages from entity class does a good work but I have some problem in the other classes.
When I call EntityManager it returns null!
The strange thing is that it works properly the first time, when I recall the EntityManager from another xhtml page and from another class the entity manager returns NULL!
So I would understand if the creation of a class for manage the EntityManagerFactory and EntityManager could help me.
Thank you for your future help!

Filippo Tenaglia wrote:
Hi all,
I have a "simple" question:
Should I create a class to manage entity manager and entity manager factory on JPA2?That question is far from complete, as the answer to this one is "depends on what you want to do!"
Why do I ask that? Because I read on J2EE tutorial:
With a container-managed entity manager, an EntityManager instance’s persistence context is automatically propagated by the container to all application components that use the EntityManager instance within a single Java Transaction Architecture (JTA) transaction.
To obtain an EntityManager instance, inject the entity manager into the application component:
@PersistenceContext
EntityManager em;
Given this information...
I'm using JSF2, JPA2, JTA and Glassfish3.1 on the NetBeans 7.0.1.That answer to your question is "NO", because you have a container available to you that can do the work (Glassfish). It makes no sense using Glassfish and then purposely ignoring the features it has to offer.
Lets get back to basics: you are doing something wrong here. You have to figure out what, you can only do that if you keep studying and getting a more complete understanding. If you are having trouble realizing that, perhaps you should start over without the help of any wizard at all; wizards are only useful when you are already experienced, right now the fact that code is generated is hindering you a lot because you will have a strong impulse to believe there can be no mistake; unfortunately there is no such safety net. The fact that you used the word "weird" is enough proof of this by the way. There is nothing weird here, just a mistake being made that has to be corrected.
And for the future: what IDE (Netbeans in your case) you use to develop really makes absolutely no difference at all. What is more interesting is which version of Java your are using, which can likely be Java 6 or Java 7 nowadays.

Why not use EXTENDED persistence context?

When would you not ever use EXTENDED persistence context in a stateful session bean (which is the only EJB type it can be used in)?
To me it seems that the code is cleaner (no unnecessary merge() or whatever) and it only makes sense as a stateful session bean is used to represent conversational state over multiple client calls...by setting an EXTENDED persistence context you recognize that there is a conversation happening.
I'm not seeing when you'd not want to use EXTENDED persistence context (I understand it's not the default persistence context).
Your thoughts please...
Thanks.

For the use-case you mentioned an extended persistence context is a natural fit.
It really depends on whether the semantics of your SFSB operations call for
the references to the same entity objects to be maintained across transactions.
E.g., you might have an SFSB whose state is not derived from persistence state
but which just occasionally makes a database query as part of some of its
business operations. In that case there wouldn't be any reason to use an
extended persistence context.
--ken

What is persistence contexts collision?

I'm trying to learn more on persistence in EJB, specially about persistence context. I know than a persistence context is created when a method than requires a transaction have been called and no persistence context existed before. I also know than a persistence context is destroyed when there is no method in action than requires a transaction, except if the EntityManager scope is extended. In this case, the persistence context will be destroyed when the session bean than contains the EntityManager is going to be destroyed. I read "Pro EJB 3 Java Persistence API" by Mike Keith and Merrick Schincariol. In this e-book, it mention than two persistence contexts can collide. Collisions between persistence contexts happen when we use different kinds of EntityManager. This very special part of the book brought to me a lot of questions. I want to know more about persistence context, so these are my questions :
- First of all, how many persistence contexts from the same persistence unit (EntityManagerFactory) can exist at the same time? If more than one is possible, in which context it is possible and how the propagation works when it happen?
- Second, when I'm using a new EntityManager while a persistence context created by the same persistence unit exist, is this new EntityManager will be related to the persistence context than already exists?
- Finally, what is a collision of persistence contexts? When two persistence contexts collide? What are the consequences?
- For example, if I use a stateful session bean with an extended scope EntityManager, then I call a method of this stateful session bean than call a method of a stateless session bean, and the last method use a transaction scope EntityManager, can I get a collision of two persistence contexts? I mean, will the persistence context in the stateful session bean collide with the persistence context in the stateless session bean?
Thank you in advance from your answer.
Dominic
P.S. You can answer to me in french if it's easier for you.

morphian wrote:
Hi,
I'm a total noob. I've been reading and following examples from books but I haven't read anything about how persistence really works? How does it help my session beans to access or make transactions to the database?
How does it actually work? What if I just make direct queries from my session beans without the help of the EntityManager or the Peristence API? What's the difference?
You have to code the stuff that EntityManager and Persistence are doing for you.
Like this for example:
Customer requestCustomer = em.find(Customer.class.customerId);Does it mean that the Persistence API keeps the object alive in the Customer Entity? For how long? Until the application is closed? Complicated. Not enough info.
If so, what happens if the user opens the application again and looks for that object?
Open the app and the object will be refreshed from that data store. Hence the word "persistent".
Why can't I just make a direct query to see if that customerId exists in the database?
You can.
I hope you guys don't mind my questions... I just really want to learn this stuff and I gotta let things out of my head. Hope you can help. Thanks!This isn't the way to do it, but it's a start.
%

Java Persistence API and creation of databases

Hi All
I have designed a small address book application which uses a database to store the information. I have used the new Java Persistence API to take care of my transactions and querrys with the database. This works great for one set database which is generated the first time the application runs and is used all the time.
However I would like to make it so that the user can create a new address book (database) with a different name, I am not sure how I would do this using the Java Persistence API. I know the persistence.xml file must be placed in the META-INF directory of the source, so how would I be able manipulate the file or could I place the file somewhere else.
David

I am using the Derby database. I can create a database by passing the create command when I create the entity Manager like so:
Connection c = DriverManager.getConnection("jdbc:derby:AddressBook;create=true", "app", "app");My problem is that as I understand it the persistence.xml file must know the name of the database. Unless there is another way of setting this. The line in the persistence file I am referring to is:
<property name="toplink.jdbc.url" value="jdbc:derby:AddressBook"/>I wonder if I can progamatically set this value so that I have a default database in the persistence.xml and others can then create there own.
David

Is Persistence context thread safe? nop

In my code, i have a servlet , 2 stateless session beans:
in the servlet, i use jndi to find a stateless bean (A) and invoke a method methodA in A:
(Stateless bean A):
@EJB
StatelessBeanB beanB;
methodA(obj) {
beanB.save(obj);
(Stateless bean B, where container inject a persistence context):
@PersistenceContext private EntityManager em;
save(obj) {
em.persist(obj);
it is said entity manager is not thread safe, so it should not be an instance variable. But in the code above, the variable "em" is an instance variable of stateless bean B, Does it make sense to put it there using pc annotation? is it then thread safe when it is injected (manager) by container?
since i think B is a stateless session bean, so each request will share the instance variable of B class which is not a thread safe way.
So , could you please give me any guide on this problem? make me clear.
any is appreciated. thank you
and what if i change stateless bean B to
(Stateless bean B, where container inject a persistence context):
@PersistenceUnit private EntityManagerFactory emf;
save(obj) {
em = emf.creatEntityManager()
//begin tran
em.persist(obj);
// commit tran
//close em
the problem is i have several stateless beans like B, if each one has a emf injected, is there any problem ?

Hi Jacky,
An EntityManager object is not thread-safe. However, that's not a problem when accessing an EntityManager from EJB bean instance state. The EJB container guarantees that no more than one thread has access to a particular bean instance at any given time. In the case of stateless session beans, the container uses as many distinct bean instances as there are concurrent requests.
Storing an EntityManager object in servlet instance state would be a problem, since in the servlet programming model any number of concurrent threads share the same servlet instance.
--ken

How many ejbCreate() can be in Session and Entity Bean???

Hi,
How many ejbCreate() method can be in a Session and Entity
Bean???
How many can be in Stateless and Stateful SessionBean???
How many can be in CMP and BMP SessionBean???
Thanks,
JavaCrazyLover

How many ejbCreate() method can be in a Session
ion and Entity
Bean???For Stateful Session Beans and Entity Beans, as many as you'd like.
Stateless Session beans can only have one, since their ejbCreate methods can not take any parameters.
>
>
How many can be in CMP and BMP SessionBean???If you mean CMT/BMT(Container-Managed transactions / Bean-Managed Transactions), then
the answer is the same. The create method requirements are independent of the transactional nature of the bean.
If you really mean CMP/BMP(Container-Managed Persistence / Bean-Managed Persistence) , it doesn't apply to session beans, only entity beans. However, even for entity beans, CMP vs. BMP has no bearing on the rules regarding # of create methods.
--ken
>
>
Thanks,
JavaCrazyLover

Multiple persistence units and OneToMany associations

Hi,
I have an EAR with two persistence units and corresponding entities. Each is contained within a separate library jar file. Some of the entities in one of the jars refer to entities in the other jar. If I refer to just a single entity (i.e., a OneToOne association), everything builds and deploys with no problems, but if I use a collection (OneToMany association), I get errors when trying to deploy the project.
I've been playing around with this for a while and have seen different errors such as the following:
[exec] CLI171 Command deploy failed : Deploying application in domain failed; Exception [TOPLINK-28018] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))): oracle.toplink.essentials.exceptions.EntityManagerSetupException
[exec] Exception Description: predeploy for PersistenceUnit [GrammarUserData] failed.
[exec] Internal Exception: Exception [TOPLINK-7155] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))): oracle.toplink.essentials.exceptions.ValidationException
[exec] Exception Description: The type [interface java.util.List] for the attribute [sentencePatterns] on the entity class [class com.leadingstep.grammar.configuration.CommonElementConfiguration] is not a valid type for a serialized mapping. The attribute type must implement the Serializable interface.
I also had the collection defined as a Set and it complained about that as well. I have many other OneToMany associations used between entities within the same persistence unit that use the List interface with no problems, and so that's why I'm wondering if the problem actually comes from the fact that the entities in the failed case belong to different persistence units?
At another point, the error message I was getting was:
[#|2009-12-22T20:05:02.427-0500|SEVERE|sun-appserver9.1|javax.enterprise.system.tools.deployment|_ThreadID=15;_ThreadName=Thread-32;_RequestID=67ca0eee-64d9-41dc-8093-eec811cb32b6;|Exception occured in J2EEC Phase
com.sun.enterprise.deployment.backend.IASDeploymentException: Exception [TOPLINK-28018] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))): oracle.toplink.essentials.exceptions.EntityManagerSetupException
Exception Description: predeploy for PersistenceUnit [GrammarUserData] failed.
Internal Exception: Exception [TOPLINK-7250] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))): oracle.toplink.essentials.exceptions.ValidationException
Exception Description: [class com.leadingstep.grammar.configuration.CommonConstructorConfiguration] uses a non-entity [class com.leadingstep.grammar.db.sentences.SentenceGroup] as target entity in the relationship attribute [private java.util.List com.leadingstep.grammar.configuration.CommonConstructorConfiguration.sentenceGroups].
The target entity it refers to here definitely has the @Entity annotation and again, is associated with other entities within the same persistence unit with no problems.
Am I right in thinking the problem comes from the association of entities between the different persistence units? Is there something special I have to do to make this work?
BTW, both persistence units use the <exclude-unlisted-classes> and specifically list every entity that should be included.
Thanks for any help!
Renee

One other thought on this. I'm using Glassfish with Toplink and have it create the tables using:
<property name="toplink.ddl-generation" value="create-tables" />
Could it be something related to the table creation in this case that's causing the problem?
Renee

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

Sharing transaction between regions and creating new records

Hi all,
To simplify my scenario, I will use HR scema.
I have a fragment department.jsff. This one is showing records from a Departments table in a panelFormLayout. In here I have a button NEW that is bound to the CreateInsert operation from Deparment collection from HRDataControl. (so the ActionListener for the button is "#{bindings.CreateInsert.execute}".
This department.jsff has a task flow as a region (customer-tf) with input parameter. So in departmentPageDef, customer-tf is an executable with Refresh:ifNeeded and a parameter value: #{bindings.DepartmentId.inputValue}. The customer-tf, has as a default activity method call - which based on the input parameter value executes a query (viewcritwria) for Customer table, and than shows in a table Customer collection from HRDataControl.
So far so good. When I run the page, first record from Departnent collection is displayed in the form, the right value #{bindings.DepartmentId.inputValue} is passed as a input value to customer-tf, proper query is done for Customer collection and proper customer records are displayed in the customer region.
The problem I have is when the New button is pressed.
If on customer-tf for Transaction behavior I set: <No Controller Transaction> and "Share data controls with calling task flow" unchecked (so isolated), than when New button is pressed, new department record is created, and customer table shows no records. The customer-tf was restarted with a input parameter value of -10 (since DepartmentId is of type oracle.jbo.domain.DBSequence in Department table.) That is excellant.
But I want to share transaction. So if on customer-tf for Transaction behavior I set: <Use existing Transaction if possible> and "Share data controls with calling task flow" checked (so shared), I am tracing that new record is created in Department entity, but customer-tf is restarted with the old value of DeparmentId #{bindings.DepartmentId.inputValue}. New record is never shown on the page.
I want to be able to share transaction and data control. Somehow is second scenario, like a sharing prevents bindings value (#{bindings.DepartmentId.inputValue}) to get new value of -10.
Am I doing anything wrong??

I have figured it out.
The transaction management and sharing data controls.
It is different when the task-flow:
a) is a region inside a page or fragment (in here you are controlling only sharing data controls declaratively)
b) is called with a task low call activity from another flow and has a task flow return point (in here you are controlling transaction declaratively + sharing data controls)
I figured out this by carefully rereading from Fusion Developers Guide: chapter 18.3 (Managing transactions) , and chapter 16.4 (Sharing data control instances)
Regards

Persistence Context In EJB 3.0

I created an EJB 3.0 project in JDeveloper 10.1.3.3.0 and everything works fine in the embedded OC4J server. I am deploying the application to an OC4J instance consisting of 3 Java Virtual Machines in Oracle Application server 10.1.3 and seem to be getting a different persistence context for each virtual machine. i.e. I'll have 3 browsers that can view the same data even after updating, another 2 browsers that can't see the first 3's changes but can see changes by any browser in this group, etc.
I tried adding the below to the persistence-unit tag in the persistence.xml but it didn't seem to help.
<properties>
<property name="toplink.cache.shared.default" value="true"/>
</properties>
How do you get all connections to use the same cache?

Hi,
I am afraid, but this seems to be less a question for the JDeveloper forum but OC4J
OC4J
Frank

Javax.persistence.NoResultException: No entity help

here is a my method
public WnUser findUser (Object email) {
return (WnUser) em.createQuery("SELECT object(u.email) FROM entities.WnUser u WHERE u.email =:email")
.setParameter("email", email).getSingleResult();
when I call this I see errors
2:23:44,843 ERROR [STDERR] javax.ejb.EJBException: javax.persistence.NoResultException: No entity found for query
12:23:44,843 ERROR [STDERR]      at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:63)
12:23:44,843 ERROR [STDERR]      at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
12:23:44,843 ERROR [STDERR]      at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
12:23:44,843 ERROR [STDERR]      at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
12:23:45,281 ERROR [STDERR]      at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
12:23:45,281 ERROR [STDERR]      at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
I want write method fro login by email and password, also I want search email with entity beans, nut I have this errors, what is it?

Seems this is happening because your query finds no result.
If you look at the javadoc for javax.persistence.Query, you can see that method getSingleResult() throws a NoResultException if there is no result.

Transactions, Persistence Contexts and Entity Managers... Oh My!

Similar Messages

Maybe you are looking for