Session and carrying 3rd party state
by Emmanuel Bernard
I took some more time to think about our conversation from 2 IRC meeting ago
about offering the ability to carry session bound state not related to
ORM per se.
Below is a sum and a potential solution.
If you are short on time, read Goals, then the SessionSessionEventListener
approach and ignore the rest.
## Goals
The goal is to be able to carry session bound state for non-ORM projects
like search and OGM.
We want to avoid ThreadLocal use, in particular when it cannot be
protected by a try / catch for proper resource cleaning.
We want to avoid a structure that would be shared across threads concurrently
i.e. using ConcurrentHashMap with a Weak reference to the session.
It needs to be informed of a call to session.clear()
It needs to be informed of a call to session.close()
The state needs to be accessed from event listener implementations and custom
persister / loader implementations i.e. SessionImplementor and maybe
EventSource?
## Approaches
I'll discuss the approaches we explored in the meeting and then offer an
alternative one that I think is pretty interesting and fit better with
the current Session model.
### Map
This is essentially sticking a map on SessionImpl and use it to carry
state.
The following is a pseudo implementation
/**
* interface implemented by SessionImpl and the like
*/
interface SessionCompanion {
Object getCompanion(String key);
void addCompanion(String key, Object companion);
void removeCompanion(String key);
}
/**
* adds a map to the SessionImpl
*/
SessionImpl {
private Map<String, Object> companions;
public Object getCompanion(String key) { return companions.get(key); }
public void addCompanion(String key, Object value) { companions.add(key, companion); }
public void removeCompanion(String key) { companions.remove(key) }
}
The persister or event listener would call SessionCompation.*Companion method
to put and retrieve its state.
There is no clear / close event listener loop and it would need to be added.
### Delegator
Gunnar and teve discussed an approach where the delegator would be passed to
the underlying session and be accessible via an `unwrap` method.
I have not followed the details but this approach has one major flaw: the
delegator (OgmSession, FullTextSession etc) is not always created and thus
would not be necessarily available.
A somewhat similar idea involving passing the session owner has the same
drawback. And another one described by Gunnar in
https://hibernate.atlassian.net/browse/OGM-469
### The type-safe map approach
This approach is vaguely similar to the Map approach except that the payload is
represented and looked up by Class. This has the benefit of not having
namespace problems and is generally less String-y.
/**
* interface implemented by SessionImpl and the like
*/
interface SessionCompanion {
T getCompanion(Class<T> type);
void addCompanion(Object companion);
void removeCompanion(Class<?> type)
}
SessionImpl {
//could also use an array or an ArrayList
private Map<Class<?>, Object> companions;
public T getCompanion(Class<T> type) { return (T) companions.get(type); }
public void addCompanion(Object companion) { companions.add(companion.getClass(), type); }
public void removeCompanion(Class<T> type) { companions.remove(type); }
}
Like in the Map approach, the persister or custom event listener would interact
with SessionCompanion.
There are open issues like what should be done when two objects of the same
type are added to the same session.
Likewise the clear / close hook issues need to be addressed.
### the SessionEventListener approach
I did not know but there is a concept of `SessionEventListener` which can be
added to a `SessionImplementor`. It has hooks that are addressing most of the
goals.
//interface already exists
interface SessionImplementor {
public SessionEventListenerManager getEventListenerManager();
}
//interface already exists
public interface SessionEventListenerManager extends SessionEventListener {
// add this method to be able to retrieve a specific listener holding some state for a 3rd party project
List<SessionEventListener> getSessionEventListeners();
}
OGM or Search would implement a `SessionEventListener` and attach an instance to a session via `Session.addEventListeners()`.
It would require to add a method to retrieve the list of `SessionEventListener`s attached to a `SessionEventListenerManager`.
List<SessionEventListeners> listeners = sessionImplementor.getSessionEventListenerManager().getEnlistedListeners();
OgmSessionEventListener ogmListener = findOrAddOgmListener(sessionImplementor, listeners);
ogmListener.someStuff();
## What about clear and close?
We have a few ways to react to these.
SessionEventListener is already called back when a flush begins / ends as well as when Session closes.
We need to either:
- add a clear begins / ends callback
- have the third party project add a ClearEventListener which would access the SessionEventListeners and do some magic.
The first approach has my preference and would do:
public interface SessionEventListener {
[...]
void clearStart();
void clearEnd();
}
What do you guys think? The SessionEventListener approach feels more natural.
Emmanuel
11 years, 11 months
Lucene moving to Java7
by Sanne Grinovero
The next minor release of Apache Lucene v. 4.8 will require Java7.
The Lucene team has highlighted many good reasons for that, including
some excellent improvements in sorting performance and reliability of
IO operations: nice things we'd like to take advantage of.
Objections against baseling Hibernate Search 5 to *require* Java7 too?
We hardly have a choice, so objections better be good ;-)
-- Sanne
11 years, 11 months
Delivery Failure
by Postmaster
---------------------------------------------------------------------------------
The message you sent to amigosenmarcha.org/informacion was rejected because it would exceed the quota for the mailbox.
The subject of the message follows:
Subject: Vacancy - apply online
---------------------------------------------------------------------------------
11 years, 11 months
Fix for the Eclipse formatter
by Guillaume Smet
Hi,
Here is a fix for the Eclipse formatter posted on the community site.
Currently, it changes:
x.<String, Element>foo();
to
x.<String, Element> foo();
which doesn't respect the checkstyle rules.
Thought it might be useful to report it as it's quite painful to have
a build broken because of that.
Thanks!
--
Guillaume
11 years, 11 months
Attribute paths and '.' versus '#' as separator
by Steve Ebersole
This is a bit of a potentially insidious one. Not the best way to start
off a discussion, I know :)
The premise is this... Until now Hibernate has represented attribute roles
using dots. For an attribute named 'department' on the com.acme.Employee
entity, the role would be "com.acme.Employee.department". In terms of
embeddables, say Employee had an 'address' embedded with its own attributes
like 'city'. Then, the full role for 'city' would be
"com.acme.Employee.address.city".
As you can start to see the dots here are completely indistinguishable in
terms of those which define the package/class and those which identify the
attribute "path".
So one of the things I started playing with in 5 is to replace the
separators used in attribute paths to use '#', such that
"com.acme.Employee.address.city" would instead be
"com.acme.Employee#address#city". This makes the role fully parseable
which is actually useful in quite a few situations. And it REALLY helps in
things I have just started working on like storing metadata for composites
(embeddeds/embeddables) on the SessionFactory, which is the first step in
support for some cool new features around embeddables like discriminated
inheritance support.
However, there is a minor drawback. Like all attributes, collections have
a role. Unfortunately the use of '.' in their role Strings leaks into the
SPI in terms of locating the CollectionPersisters.
So the question is whether to continue with this path of replacing the use
of '.' with '#' for attribute path separators. The drawback is
unfortunate. The benefit is very nice, but I can't really say it is
required atm.
Votes? Thoughts?
11 years, 11 months
Tests asserting warnings get logged
by Steve Ebersole
I again have in mind adding some test assertions that a particular logging
(WARN) message gets triggered. We have already one such test in place,
which is one of the places where our usage of byteman comes in.
Given the problems using byteman is causing in CI and the fact that our
reliance on it is pretty light at the moment, I wanted to reach out for
some other ideas/proposals for ways to handle this testing requirement. I
will also reach out to David and James to see if this is something JBoss
Logging itself could help us tackle; maybe there is some feature there
already that would help. Any other ideas/proposals?
11 years, 11 months
Build failure executing :hibernate-core:runAnnotationProcessors
by Gail Badner
After pulling, I am getting a failure executing :hibernate-core:runAnnotationProcessors.
I tried building with --debug and it looks like the hibernate-core/target/generated-src/apt/main is deleted without being re-generated. When hibernate-core is compiled, there are failures because package org.hibernate.hql.internal.antlr does not exist.
Anyone have ideas why this is happening?
Thanks,
Gail
11 years, 11 months
Re: [hibernate-dev] Welcome to the "hibernate-dev" mailing list (Digest mode)
by 秋雪 佛
hello,i am chinese ,so my english is not good ,sorry! i use hibernate orm + jdts.13 connection sqlserver 2008 , and there are a class of User .
class User
{
....
private Blob pictureImg;
......
}
when i save user ,i got a problem " net.sourceforge.jtds.jdbc.JtdsPreparedStatement.setBinaryStream(JtdsPreparedStatement.java:1234) ", i know jtds do not implement the method " setBinaryStream" .
but i use hibernate 3 ,it's work well, why? has hibernate-release-4.3.4.Final this " bug" ,i hope your reply,thank you
11 years, 11 months
"derived identifier" mapping
by Steve Ebersole
What's the rational for supporting the following?
@Entity
class Product {
...
}
@Entity
class Order {
...
}
@Entity
@IdClass(...)
class OrderLine {
@Id
private Order order;
@Id
private Product product;
}
Specifically, the declaration of the OrderLine primary key. Why would
these not have to be `@Id @ManyToOne`?
11 years, 11 months
Metamodel, Jandex and "XML mixins"
by Steve Ebersole
I was looking into some failures on master in regards to XML overrides for
JPA annotations in relation to our friend Access/AccessType. Which got me
to thinking...
How does the "mixin" code handle defining the target for the
AnnotationInstances it creates?
Seems to me this code would have really no idea whether to choose the field
or the getter as the target. Which is potentially problematic as we are
validating the "placement" of these annotations.
Strong? Hardy?
Maybe we need to look at adding a virtual notion of the attribute as the
target in the virtual AnnotationInstance?
11 years, 11 months
