Markus,
I use both in the same TX. So using the same connection is the only way
to keep the data consistent. Otherwise you would really have to use XA.
On WLS 10 it worked without XA - the configuration was very similar...
However the connection is only my suspicion. Aggresive caching could be
the cause as well...
regards,
adam
Markus KARG schrieb:
> Adam,
>
> what makes you so certain that the EntityManager and the DataSource
> are using technically the same JDBC Connection instance (unless they
> will do, they will end up with two different connections provided over
> the same physical link)? I mean, unless you take explicit care for
> that, the EntityManager will use a different JDBC Connection provided
> by the same DataSource.
>
> Have Fun
> Markus
>
> Adam Bien schrieb:
>> Markus,
>>
>> you are right, but actually I do not want to have 2PC. I would
>> expect, that the EntityManager as well as the DataSource would use
>> exactly the *same* connection.
>> Both are accessing the same resource - so 2PC / XA are actually not
>> needed. The application server should not initiate a
>> two-phase-commit protocol in this case.
>>
>> thank you for the link and help!,
>>
>> adam
>>
>> Markus KARG schrieb:
>>> Adam,
>>>
>>> I guess that the problem is that you declared the connection factory
>>> to use DataSource instead of XADataSource. AFAIK only XADataSource
>>> can participate in distributed TX, while DataSource always will use
>>> a local (different) exception. At least this is what I have
>>> understood from the JDBC spec what the main difference between
>>> DataSource and XADataSource is. See
>>> http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/xadistra.htm#i1066469.
>>> Can you try the same use case with "|OracleXADataSource| " instead
>>> of "OracleDataSource" and "XADataSource" instead of "DataSource"?
>>> Maybe that will help. :-)
>>>
>>> Have Fun
>>> Markus
>>>
>>> Adam Bien schrieb:
>>>> Forgot screenshot / configuration,
>>>>
>>>> adam
>>>>
>>>> Adam Bien schrieb:
>>>>> Hi All,
>>>>>
>>>>>
>>>>>
>>>>> I ran into following problem: Direct changes in the database (SQL
>>>>> updates) performed in the same Bean-method, and so transaction,
>>>>> are not visible for the EntityManager (subsequent find).
>>>>>
>>>>> Even invoking EntityManager#clear does not solve the problem. The
>>>>> problem is strange, I suspect that the DB-connection from the
>>>>> datasource does not participate in the TX. This would explain such
>>>>> behaviour.
>>>>>
>>>>>
>>>>>
>>>>> Server: Glassfishv2u2
>>>>>
>>>>> Database: OracleXE
>>>>>
>>>>>
>>>>>
>>>>> The Bean looks like:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> @Stateless
>>>>>
>>>>> @Remote(VehicleManager.class)
>>>>>
>>>>> @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
>>>>>
>>>>> public class VehicleManagerBean implements VehicleManager {
>>>>>
>>>>>
>>>>>
>>>>> @PersistenceContext
>>>>>
>>>>> private EntityManager entityManager;
>>>>>
>>>>> @Resource(mappedName = "jdbc/db1")
>>>>>
>>>>> * private DataSource dataSource;*
>>>>>
>>>>> @EJB
>>>>>
>>>>> private DataService dataService;
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> public Vehicle findChangeDBClearFind(int id, String newColor) {
>>>>>
>>>>> Vehicle vehicle = this.find(id);
>>>>>
>>>>> try {
>>>>>
>>>>>
>>>>>
>>>>> //changes the color of the vehicle directly in the DB
>>>>>
>>>>> * this.changeVehiclesColor(id, newColor);*
>>>>>
>>>>> * * } catch (Exception e) {
>>>>>
>>>>> throw new EJBException("Problem executing statement" +
>>>>> e, e);
>>>>>
>>>>> }
>>>>>
>>>>> this.entityManager.clear();
>>>>>
>>>>> return this.find(id);
>>>>>
>>>>> }
>>>>>
>>>>> private void changeVehiclesColor(int id, String color) throws
>>>>> Exception {
>>>>>
>>>>> Connection connection = this.dataSource.getConnection();
>>>>>
>>>>> Statement statement = connection.createStatement();
>>>>>
>>>>> String sqlStatement = "update vehicle set color=\'" + color
>>>>> + "\' where id=" + id;
>>>>>
>>>>> System.out.println(sqlStatement);
>>>>>
>>>>> int updatedRecords = statement.executeUpdate(sqlStatement);
>>>>>
>>>>> if (updatedRecords != 1) {
>>>>>
>>>>> throw new IllegalStateException("Vehicle with id: " +
>>>>> id + " cannot be updated!");
>>>>>
>>>>> }
>>>>>
>>>>> connection.close();
>>>>>
>>>>> statement.close();
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I deployed the same code to WLS 10 and it worked - the changes
>>>>> were visible. I suppose it is probably a configuration problem. I
>>>>> tried with different DataSource configurations - with no effect. I
>>>>> attached my current configuration as well (screenshot).
>>>>>
>>>>>
>>>>>
>>>>> Hopefully I overlooked something. If not - I will file it as a bug.
>>>>>
>>>>>
>>>>>
>>>>> Thank you in advance,
>>>>>
>>>>>
>>>>>
>>>>> regards,
>>>>>
>>>>>
>>>>>
>>>>> adam bien
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>
>>>
>>
>>
>
>
--
Consultant, Author, Java Champion
Homepage: www.adam-bien.com
Weblog: blog.adam-bien.com
eMail: abien_at_adam-bien.com
Mobile: 0049(0)170 280 3144
Books: Enterprise Architekturen (ISBN: 393504299X),
Java EE 5 Architekturen (ISBN: 3939084247),
J2EE Patterns, J2EE Hotspots, Enterprise Frameworks and Struts