Hi,
I have several comments
1. Firebird and Interbase have default snapshot transaction isolation.
This is almost serializable. All reads are indeed within a transaction (as
correct transactional semantics require -- if you think about it for a
minute, read committed is just plain broken as far as logical consistency).
You leave out a lot of details such as how much work is in one
transaction, it is hard to know just what is going on. You might try using
the interbase connection methods get/setLockResolution to make sure lock
contention is waiting rather than immediately returning an exception, and
for this presumably "info" request you might try setting the transaction
isolation level lower, again with connection properties. If you are using
the non JCA minerva pools, I believe you can set these in the properties of
the XADataSourceImpl, in the same section as the user name and password.
(I'm not 100% sure, its been a while). I think you can set them in the
<attribute name="Properties">
section if you are using the JCA with for example BlackBox adapter.
2. Even if you fix this, you probably have 2 design problems if you are
calling findAll on a bean with any number of instances. If you are sending
the data out of the container, you don't want to hold anything in a
transaction while a slow human looks at it, so there's no particular reason
to go to all the trouble of loading beans for all those rows that aren't
going to change. Most authors I have read ( such as Richard Monson-Hefael)
suggest using a query from a stateless session bean, and just making a
collection or some text or xml to get the viewable data out. Then when the
user decides what to do, you load just the beans they actually need. I
don't find this terribly elegant, but you really don't want to keep
involving entire tables in transactions when nothing is changing in most of
it. There is also a user interface question, if there are more than say 10
rows in this table, why are you overwhelming the user with data?
So I've made a lot of assumptions here about what you are trying to do, and
made a couple of suggestions. If you are trying to do something else,
please say so.
Thanks
david jencks
On 2001.04.26 16:32:17 -0400 Sven Van Caekenberghe wrote:
> Hi all you jboss/ejb gurus,
>
> While stress-testing an application using jboss we encountered some
> problems. We're not sure whether we did something wrong in the ejb
> development or in the deployment or what. We think we need at least some
> help in how to do 'readonly beans/transactions'.
>
> Problem description:
>
> System: jboss 2.2.x, interbase 6.x, jdk 1.3, linux mandrake 7.2
> Server code: session bean facades working with multiple entity beans
> (some with subobjects)
> Deployment: container managed persistence and transactions, requied
> transactions, default commit option A
> Client code: swing gui clients, junit tests clients
>
> Problem: Running more than one client we get locking-waiting, lock
> contention, but sometimes also failed transactions. The thing is that
> you would expect these problems when trying to modify the same object,
> but it also seems to happen when reading data from the same object
> (which of course happens a lot). It seems that even a call like
> PersonData[] getAllPersons() on a session bean (returning serializable
> copies of entity beans) needs full exclusive read/write locks on all
> objects involved in the transaction, even if we are just reading data.
> As we see it, such behavior will never scale.
>
> Question: How do you do readonly beans or access beans in readonly
> transactions, either in ejb or in jboss? This must be a common
> situation. I hope the answer is not to avoid using entity beans for
> readonly data access and to access the database/datasource directly (we
> like cmp too much to let it go).
>
> All help is greatly appreciated!
>
> Sven
>
> ---
> Sven Van Caekenberghe - mailto:[EMAIL PROTECTED]
> Beta Nine - software engineering - http://www.beta9.be
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
